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.4.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' externalDocs: description: ETSI GS NFV-SOL 003 V3.7.1 url: >- https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/03.07.01_60/gs_NFV-SOL003v030701p.pdf servers: - url: 'http://127.0.0.1/vnfpkgm/v2' - url: 'https://127.0.0.1/vnfpkgm/v2' paths: /api_versions: parameters: - 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 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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 9110 for the use of the "Retry-After" HTTP header and for closing the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '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 content type of the message content is supported and 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. More details are defined in IETF RFC 9110. 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 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 the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 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 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 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 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 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 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 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 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 /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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '422': description: > 422 UNPROCESSABLE Content If the content type of the message content is supported and 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. More details are defined in IETF RFC 9110. 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 the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 /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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '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 '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '409': $ref: '#/components/responses/VnfdInIndividualVnfPackage.Get.409' '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 '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '409': $ref: '#/components/responses/VnfdInIndividualOnboardedVnfPackage.Get.409' '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 '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '406': $ref: '#/components/responses/ManifestInIndividualVnfPackage.Get.406' '409': $ref: '#/components/responses/ManifestInIndividualVnfPackage.Get.409' '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 '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '406': $ref: >- #/components/responses/ManifestInIndividualOnboardedVnfPackage.Get.406 '409': $ref: >- #/components/responses/ManifestInIndividualOnboardedVnfPackage.Get.409 '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 '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '409': $ref: '#/components/responses/IndividualVnfPackageContent.Get.409' '416': $ref: '#/components/responses/IndividualVnfPackageContent.Get.416' '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '409': $ref: '#/components/responses/IndividualOnboardedVnfPackageContent.Get.409' '416': $ref: '#/components/responses/IndividualOnboardedVnfPackageContent.Get.416' '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/vnf_packages/{vnfPkgId}/artifacts': parameters: - $ref: '#/components/parameters/VnfPkgId' get: description: > The GET method shall return an archive that contains a set of artifacts according to the provisions for inclusion/exclusion defined below, embedded in a directory structure being the same as in the VNF package. See clause 10.4.5a.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' - $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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '409': $ref: '#/components/responses/IndividualVnfPackageArtifacts.Get.409' '416': $ref: '#/components/responses/IndividualVnfPackageArtifacts.Get.416' '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/onboarded_vnf_packages/{vnfdId}/artifacts': parameters: - $ref: '#/components/parameters/VnfdId' get: description: > The GET method shall return an archive that contains a set of artifacts according to the provisions for inclusion/exclusion defined below, embedded in a directory structure being the same as in the VNF package. See clause 10.4.5a.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' - $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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '409': $ref: >- #/components/responses/IndividualOnboardedVnfPackageArtifacts.Get.409 '416': $ref: >- #/components/responses/IndividualOnboardedVnfPackageArtifacts.Get.416 '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '409': $ref: '#/components/responses/IndividualVnfPackageArtifact.Get.409' '416': $ref: '#/components/responses/IndividualVnfPackageArtifact.Get.416' '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '409': $ref: '#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.409' '416': $ref: '#/components/responses/IndividualOnboardedVnfPackageArtifact.Get.416' '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 /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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '422': $ref: '#/components/responses/Subscriptions.Post.422' '500': description: > 500 INTERNAL SERVER ERROR If the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '422': description: > 422 UNPROCESSABLE Content If the content type of the message content is supported and 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. More details are defined in IETF RFC 9110. 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 the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 '/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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '422': description: > 422 UNPROCESSABLE Content If the content type of the message content is supported and 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. More details are defined in IETF RFC 9110. 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 the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 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. More details are defined in IETF RFC 9110. 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. Clause 5.4.2.2 specifies provisions for the "ProblemDetails" structure provided in the response body. 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. 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 8.3.3 and 8.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 9110. 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. More details are defined in IETF RFC 9110. The "ProblemDetails" structure 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. A typical reason for this error can e.g. be that resource URI variables were set wrongly. More details are defined in IETF RFC 9110. The "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 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 '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 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 '422': description: > 422 UNPROCESSABLE Content If the content type of the message content is supported and 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. More details are defined in IETF RFC 9110. 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 the Server is unable to process the request, and retrying the same request later might eventually succeed, the server shall respond with this response code. Further, 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. More details are defined in IETF RFC 9110. 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 9110 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. 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 '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. More details are defined in IETF RFC 9110. 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 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. 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).\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: 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 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: * BASIC: In every HTTP request to the notification endpoint, use HTTP Basic authentication with the client credentials. * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use an OAuth 2.0 Bearer token, obtained using the client credentials grant type. * TLS_CERT: Every HTTP request to the notification endpoint is sent over a mutually authenticated TLS session, i.e. not only the server is authenticated, but also the client is authenticated during the TLS tunnel setup. type: array items: type: string enum: - BASIC - OAUTH2_CLIENT_CREDENTIALS - TLS_CERT paramsBasic: description: > Parameters for authentication/authorization using BASIC. Shall be present if authType is "BASIC" and the contained information has not been provisioned out of band. Shall be absent otherwise. type: object properties: userName: description: > Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band. type: string password: description: > Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band. 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. type: object properties: clientId: description: > Client identifier 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. 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. 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 - _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 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.\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 - provider - version - checksum - isEncrypted - containerFormat - diskFormat - createdAt - minDisk - minRam - 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 note 2. 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. type: integer minRam: description: | The minimal RAM for this software image in bytes. 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: > Specifies VNFMs compatible with the VNF. This information is copied from the VNFD of the on-boarded VNF package. See note 3. It shall be present after the VNF package content has been on-boarded and absent otherwise. type: array items: 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 - _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 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.\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 - provider - version - checksum - isEncrypted - containerFormat - diskFormat - createdAt - minDisk - minRam - 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 note 2. 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. type: integer minRam: description: | The minimal RAM for this software image in bytes. 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: > Specifies VNFMs compatible with the VNF. This information is copied from the VNFD of the on-boarded VNF package. See note 3. It shall be present after the VNF package content has been on-boarded and absent otherwise. type: array items: 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 - _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 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.\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 - provider - version - checksum - isEncrypted - containerFormat - diskFormat - createdAt - minDisk - minRam - 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 note 2. 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. type: integer minRam: description: | The minimal RAM for this software image in bytes. 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: > Specifies VNFMs compatible with the VNF. This information is copied from the VNFD of the on-boarded VNF package. See note 3. It shall be present after the VNF package content has been on-boarded and absent otherwise. type: array items: 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 ZIP archive that contains the files representing the VNFD, as specified above. The "Content-Type" HTTP header shall be set to "application/zip". 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 messgae 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. 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. 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 has been read successfully according to the request. The response body shall contain the requested part of the artifact file from the VNF package, as defined by ETSI GS NFV-SOL 004. 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. 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. 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 9110. 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 messgae 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 has been read successfully according to the request. The response body shall contain the requested part of the artifact file from the VNF package, as defined by ETSI GS NFV-SOL 004. 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. 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. 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).\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 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 NFVO has tested the Notification endpoint as described in clause 10.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. 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. 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).\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. 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).\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