openapi: 3.0.2 info: title: SOL003 - VNF Lifecycle Management Notification interface description: | SOL003 - VNF Lifecycle Management Notification interface IMPORTANT: Please note that this file might be not aligned to the current version of the ETSI Group Specification it refers to. In case of discrepancies the published ETSI Group Specification takes precedence. Please report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues contact: name: NFV-SOL WG license: name: ETSI Forge copyright notice url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt' version: '2.2.0-impl:etsi.org:ETSI_NFV_OpenAPI:1' externalDocs: description: ETSI GS NFV-SOL 003 V3.6.1 url: >- https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/03.06.01_60/gs_NFV-SOL003v030601p.pdf servers: - url: 'http://127.0.0.1/callback/v2' - url: 'https://127.0.0.1/callback/v2' paths: /URI_is_provided_by_the_client_when_creating_the_subscription-VnfLcmOperationOccurrenceNotification: parameters: - name: Authorization description: | The authorization token for the request. Reference: IETF RFC 7235. in: header required: false schema: type: string - name: Version description: | Version of the API requested to use when responding to this request. in: header required: true schema: type: string post: description: > The POST method delivers a notification from the API producer to an API consumer. The API consumer shall have previously created an "Individual subscription" resource with a matching filter. See clause 5.4.20.3.1. requestBody: $ref: '#/components/requestBodies/VnfLcmOperationOccurrenceNotification' responses: '204': $ref: >- #/components/responses/VnfLcmOperationOccurrenceNotification.Post.204 '400': description: > 400 BAD REQUEST 400 code can be returned in the following specified cases, the specific cause has to be proper specified in the "ProblemDetails" structure to be returned. If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. The use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '401': description: > 401 UNAUTHORIZED If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '403': description: > 403 FORBIDDEN If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '405': description: > 405 METHOD NOT ALLOWED If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '406': description: > 406 NOT ACCEPTABLE If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '500': description: > 500 INTERNAL SERVER ERROR If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '503': description: > 503 SERVICE UNAVAILABLE If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI get: description: > The GET method allows the API producer to test the notification endpoint that is provided by the API consumer, e.g. during subscription. See clause 5.4.20.3.2. responses: '204': $ref: '#/components/responses/VnfLcmOperationOccurrenceNotification.Get.204' '400': description: > 400 BAD REQUEST 400 code can be returned in the following specified cases, the specific cause has to be proper specified in the "ProblemDetails" structure to be returned. If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. The use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '401': description: > 401 UNAUTHORIZED If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '403': description: > 403 FORBIDDEN If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '405': description: > 405 METHOD NOT ALLOWED If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '406': description: > 406 NOT ACCEPTABLE If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '500': description: > 500 INTERNAL SERVER ERROR If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '503': description: > 503 SERVICE UNAVAILABLE If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI /URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierCreationNotification: parameters: - name: Authorization description: | The authorization token for the request. Reference: IETF RFC 7235. in: header required: false schema: type: string - name: Version description: | Version of the API requested to use when responding to this request. in: header required: true schema: type: string post: description: > The POST method delivers a notification from the API producer to an API consumer. The API consumer shall have previously created an "Individual subscription" resource with a matching filter. See clause 5.4.20.3.1. requestBody: $ref: '#/components/requestBodies/VnfIdentifierCreationNotification' responses: '204': $ref: '#/components/responses/VnfIdentifierCreationNotification.Post.204' '400': description: > 400 BAD REQUEST 400 code can be returned in the following specified cases, the specific cause has to be proper specified in the "ProblemDetails" structure to be returned. If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. The use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '401': description: > 401 UNAUTHORIZED If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '403': description: > 403 FORBIDDEN If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '405': description: > 405 METHOD NOT ALLOWED If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '406': description: > 406 NOT ACCEPTABLE If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '500': description: > 500 INTERNAL SERVER ERROR If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '503': description: > 503 SERVICE UNAVAILABLE If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI get: description: > The GET method allows the API producer to test the notification endpoint that is provided by the API consumer, e.g. during subscription. See clause 5.4.20.3.2. responses: '204': $ref: '#/components/responses/VnfIdentifierCreationNotification.Get.204' '400': description: > 400 BAD REQUEST 400 code can be returned in the following specified cases, the specific cause has to be proper specified in the "ProblemDetails" structure to be returned. If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. The use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '401': description: > 401 UNAUTHORIZED If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '403': description: > 403 FORBIDDEN If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '405': description: > 405 METHOD NOT ALLOWED If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '406': description: > 406 NOT ACCEPTABLE If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '500': description: > 500 INTERNAL SERVER ERROR If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '503': description: > 503 SERVICE UNAVAILABLE If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI /URI_is_provided_by_the_client_when_creating_the_subscription-VnfIdentifierDeletionNotification: parameters: - name: Authorization description: | The authorization token for the request. Reference: IETF RFC 7235. in: header required: false schema: type: string - name: Version description: | Version of the API requested to use when responding to this request. in: header required: true schema: type: string post: description: > The POST method delivers a notification from the API producer to an API consumer. The API consumer shall have previously created an "Individual subscription" resource with a matching filter. See clause 5.4.20.3.1. requestBody: $ref: '#/components/requestBodies/VnfIdentifierDeletionNotification' responses: '204': $ref: '#/components/responses/VnfIdentifierDeletionNotification.Post.204' '400': description: > 400 BAD REQUEST 400 code can be returned in the following specified cases, the specific cause has to be proper specified in the "ProblemDetails" structure to be returned. If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. The use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '401': description: > 401 UNAUTHORIZED If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '403': description: > 403 FORBIDDEN If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '405': description: > 405 METHOD NOT ALLOWED If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '406': description: > 406 NOT ACCEPTABLE If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '500': description: > 500 INTERNAL SERVER ERROR If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '503': description: > 503 SERVICE UNAVAILABLE If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI get: description: > The GET method allows the API producer to test the notification endpoint that is provided by the API consumer, e.g. during subscription. See clause 5.4.20.3.2. responses: '204': $ref: '#/components/responses/VnfIdentifierDeletionNotification.Get.204' '400': description: > 400 BAD REQUEST 400 code can be returned in the following specified cases, the specific cause has to be proper specified in the "ProblemDetails" structure to be returned. If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. The use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '401': description: > 401 UNAUTHORIZED If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '403': description: > 403 FORBIDDEN If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '405': description: > 405 METHOD NOT ALLOWED If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '406': description: > 406 NOT ACCEPTABLE If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '500': description: > 500 INTERNAL SERVER ERROR If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI '503': description: > 503 SERVICE UNAVAILABLE If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted. headers: Content-Type: description: The MIME type of the body of the response. schema: type: string maximum: 1 minimum: 1 WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. schema: type: string maximum: 1 minimum: 0 Version: description: | Version of the API used in the response. schema: type: string maximum: 1 minimum: 1 content: application/json: schema: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI components: requestBodies: VnfLcmOperationOccurrenceNotification: description: > A notification about lifecycle changes triggered by a VNF LCM operation occurrence.. content: application/json: schema: description: "This type represents a VNF lifecycle management operation occurrence notification, which informs the receiver of changes in the VNF lifecycle caused by a VNF LCM operation occurrence. It shall comply with the provisions defined in table 5.5.2.17-1. The support of the notification is mandatory. \nThis notification shall be triggered by the VNFM when there is a change in the state of a VNF LCM operation occurrence that changes the VNF lifecycle, which represents an occurrence of one the following LCM operations: - Instantiation of the VNF - Scaling of the VNF instance (including auto-scaling) - Healing of the VNF instance (including auto-healing) - Change of the state of the VNF instance (i.e. Operate VNF) - Change of the deployment flavour of the VNF instance - Change of the external connectivity of the VNF instance - Change of the current VNF package - Termination of the VNF instance - Modification of VNF instance information and/or VNF configurable properties through the \"PATCH\" \n method on the \"Individual VNF instance\" resource\n- Creation of a VNF snapshot - Reversion of the VNF instance to a VNF snapshot\nClause 5.6.2 defines the states and state transition of a VNF LCM operation occurrence, and also specifies details of the notifications to be emitted at each state transition. If this is the initial notification about the start of a VNF LCM operation occurrence, it is assumed that the notification is sent by the VNFM before any action (including sending the grant request) is taken as part of the LCM operation. Due to possible race conditions, the \"start\" notification, the grant request and the LCM operation acknowledgment (i.e. the \"202 Accepted\" response) can arrive in any order at the NFVO, and the NFVO shall be able to handle such a situation. If this is a notification about a final or intermediate result state of a VNF LCM operation occurrence, the notification shall be sent after all related actions of the LCM operation that led to this state have been executed. The new state shall be set in the \"Individual VNF LCM operation occurrence\" resource before the notification about the state change is sent. The amount of information provided in the LCM operation occurrence notifications to be issued by the VNFM when a particular subscription matches can be controlled by the API consumer using the \"verbosity\" attribute in the subscription request (see clause 5.5.2.15). The \"verbosity\" setting in a particular individual subscription shall only apply to the LCM operation occurrence notifications triggered by that subscription. However, it shall not affect the amount of information in the \"VnfLcmOpOcc\" structure (see clause 5.5.2.13) which represents the \"Individual LCM operation occurrence\" resource associated with each of the notifications. See clause 5.6.2.2 for further provisions regarding sending this notification, including in cases of handling LCM operation errors.\nNOTE 1:\tShall be present if the \"notificationStatus\" is set to \"RESULT\", the \"verbosity\" attribute is set to \"FULL\" \n and the operation has performed any resource modification. Shall be absent otherwise. This attribute contains \n information about the cumulative changes to virtualised resources that were performed so far by the VNF LCM \n operation occurrence and by any of the error handling procedures for that operation occurrence.\nNOTE 2:\tFor a particular affected VL, there shall be as many \"AffectedVirtualLink\" entries as needed for signalling \n the different types of changes, i.e. one per virtual link and change type. For instance, in the case of signaling \n affected VL instances involving the addition of a particular VL instance with links ports, one \"AffectedVirtualLink\" \n entry signals the addition of the VL by using the \"changeType\" attribute of \"AffectedVirtualLink\" structure equal to \n \"ADDED\", and another \"AffectedVirtualLink\" entry signals the addition of externally visible VNF link ports of the VL \n by using the \"changeType\" equal to \"LINK_PORT_ADDED\".\nNote 3: Not more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present.\n" type: object required: - id - notificationType - subscriptionId - timeStamp - notificationStatus - operationState - vnfInstanceId - operation - isAutomaticInvocation - vnfLcmOpOccId - _links properties: id: description: | An identifier with the intention of being globally unique. type: string notificationType: description: > Discriminator for the different notification types. Shall be set to "VnfLcmOperationOccurrenceNotification" for this notification type. type: string enum: - VnfLcmOperationOccurrenceNotification subscriptionId: description: | An identifier with the intention of being globally unique. type: string timeStamp: description: > Date-time stamp. Representation: String formatted according to IETF RFC 3339. type: string format: date-time notificationStatus: description: > Indicates whether this notification reports about the start of a lifecycle operation or the result of a lifecycle operation. Permitted values: * START: Informs about the start of the VNF LCM operation occurrence. * RESULT: Informs about the final or intermediate result of the VNF LCM operation occurrence. type: string enum: - START - RESULT operationState: description: > STARTING: The LCM operation is starting. PROCESSING: The LCM operation is currently in execution. COMPLETED: The LCM operation has been completed successfully. FAILED_TEMP: The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED: The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK: The LCM operation is currently being rolled back. ROLLED_BACK: The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible. type: string enum: - STARTING - PROCESSING - COMPLETED - FAILED_TEMP - FAILED - ROLLING_BACK - ROLLED_BACK vnfInstanceId: description: | An identifier with the intention of being globally unique. type: string operation: description: > The enumeration LcmOpType defines the permitted values to represent VNF lifecycle operation types in VNF lifecycle management operation occurrence resources and VNF lifecycle management operation occurrence notifications. It shall comply with the provisions defined in table 5.5.4.5-1. Value | Description ------|------------ INSTANTIATE | Represents the "Instantiate VNF" LCM operation. SCALE | Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM operation. CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM operation. TERMINATE | Represents the "Terminate VNF" LCM operation. HEAL | Represents the "Heal VNF" LCM operation. OPERATE | Represents the "Operate VNF" LCM operation. CHANGE_EXT_CONN | Represents the "Change external VNF connectivity" LCM operation. MODIFY_INFO | Represents the "Modify VNF Information" LCM operation. CREATE_SNAPSHOT | Represents the "Create VNF Snapshot" LCM operation. REVERT_TO_SNAPSHOT | Represents the “Revert-To VNF Snapshot" LCM operation. CHANGE_VNFPKG | Represents the "Change current VNF package" LCM operation. type: string enum: - INSTANTIATE - SCALE - SCALE_TO_LEVEL - CHANGE_FLAVOUR - TERMINATE - HEAL - OPERATE - CHANGE_EXT_CONN - MODIFY_INFO - CREATE_SNAPSHOT - REVERT_TO_SNAPSHOT - CHANGE_VNFPKG isAutomaticInvocation: description: > Set to true if this VNF LCM operation occurrence has been triggered by an automated procedure inside the VNFM (i.e. ScaleVnf / ScaleVnfToLevel triggered by auto-scale, or HealVnf triggered by auto-heal). Set to false otherwise. type: boolean verbosity: description: > The enumeration LcmOpOccNotificationVerbosityType provides values to control the verbosity of LCM operation occurrence notifications. * FULL: This signals a full notification which contains all change details. * SHORT: This signals a short notification which omits large-volume change details to reduce the size of data to be sent via the notification mechanism. type: string enum: - FULL - SHORT vnfLcmOpOccId: description: | An identifier with the intention of being globally unique. type: string affectedVnfcs: description: > Information about VNFC instances that were affected during the lifecycle operation. See note 1. type: array items: description: "This type provides information about added, deleted, modified and temporary VNFCs. It shall comply with the provisions in table 5.5.3.13-1.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer \n (i.e. the NFVO) to assist in correlating the resource changes performed during \n the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management \n operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" type: object required: - id - vduId - changeType - computeResource properties: id: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string vduId: description: | An identifier that is unique within a VNF descriptor. type: string vnfdId: description: > An identifier with the intention of being globally unique. type: string changeType: description: > Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists. type: string enum: - ADDED - REMOVED - MODIFIED - TEMPORARY computeResource: required: - resourceId type: object description: > This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM. properties: vimConnectionId: description: > An identifier with the intention of being globally unique. type: string resourceProviderId: description: > An identifier with the intention of being globally unique. type: string resourceId: description: > An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance. type: string vimLevelResourceType: description: > The value set of the "vimLevelResourceType" attribute is within the scope of the VIM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2 in SOL003). type: string resourceDefinitionId: description: > An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length. type: string zoneId: description: > An identifier with the intention of being globally unique. type: string metadata: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object affectedVnfcCpIds: description: > Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance. type: array items: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string addedStorageResourceIds: description: > References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC. type: array items: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string removedStorageResourceIds: description: > References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC. type: array items: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string affectedVirtualLinks: description: > Information about VL instances that were affected during the lifecycle operation. See note 1 and note 2. type: array items: description: "This type provides information about added, deleted, modified and temporary VLs, and added or removed VNF link ports.\nNOTE 1:\tWhen signalling the addition (LINK_PORT_ADDED) or removal (LINK_PORT_REMOVED) of VNF link ports, \n the \"networkResource\" and \"resourceDefinitionId\" attributes refer to the affected virtual link \n instance, not the link port instance. The resource handles of the affected VNF link ports can be \n found by dereferencing the identifiers in the \"vnfLinkPortIds\" attribute.\nNOTE 2:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" type: object required: - id - vnfVirtualLinkDescId - changeType - networkResource properties: id: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string vnfVirtualLinkDescId: description: | An identifier that is unique within a VNF descriptor. type: string vnfdId: description: > An identifier with the intention of being globally unique. type: string changeType: description: "Signals the type of change.\nPermitted values: -\tADDED -\tREMOVED -\tMODIFIED -\tTEMPORARY -\tLINK_PORT_ADDED -\tLINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists. See note 1.\n" type: string enum: - ADDED - REMOVED - MODIFIED - TEMPORARY - LINK_PORT_ADDED - LINK_PORT_REMOVED networkResource: required: - resourceId type: object description: > This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM. properties: vimConnectionId: description: > An identifier with the intention of being globally unique. type: string resourceProviderId: description: > An identifier with the intention of being globally unique. type: string resourceId: description: > An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance. type: string vimLevelResourceType: description: > The value set of the "vimLevelResourceType" attribute is within the scope of the VIM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2 in SOL003). type: string vnfLinkPortIds: description: > Identifiers of the link ports of the affected VL related to the change. Each identifier references a "VnfLinkPortInfo" structure. Shall be set when changeType is equal to "LINK_PORT_ADDED" or "LINK_PORT_REMOVED", and the related "VnfLinkPortInfo" structures are present (case "added") or have been present (case "removed") in the "VnfVirtualLinkResourceInfo" or "ExtManagedVirtualLinkInfo" structures that are represented by the "vnfVirtualLinkResource¬Info" or "extManagedVirtualLinkInfo" attribute in the "VnfInstance" structure. See note 1. type: array items: description: | An identifier that is unique within a VNF descriptor. type: string resourceDefinitionId: description: > An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length. type: string zoneId: description: > An identifier with the intention of being globally unique. type: string metadata: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object affectedExtLinkPorts: description: > Information about external VNF link ports that were affected during the lifecycle operation. See note 1. type: array items: description: "This type provides information about added and deleted external link ports (link ports attached to external virtual links). It shall comply with the provisions in table 5.5.3.14a-1.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating \n the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which \n is identified by the \"grantId\" available in the \"Individual VNF lifecycle management operation occurrence\" and the \"id\" \n in the \"Individual Grant\".\n" type: object required: - id - changeType - extCpInstanceId - resourceHandle properties: id: description: > An identifier with the intention of being globally unique. type: string changeType: description: "Signals the type of change. Permitted values: -\tADDED - MODIFIED -\tREMOVED\n" type: string enum: - ADDED - REMOVED extCpInstanceId: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string resourceHandle: required: - resourceId type: object description: > This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM. properties: vimConnectionId: description: > An identifier with the intention of being globally unique. type: string resourceProviderId: description: > An identifier with the intention of being globally unique. type: string resourceId: description: > An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance. type: string vimLevelResourceType: description: > The value set of the "vimLevelResourceType" attribute is within the scope of the VIM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2 in SOL003). type: string resourceDefinitionId: description: > An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length. type: string affectedVirtualStorages: description: > Information about virtualised storage instances that were affected during the lifecycle operation. See note 1. type: array items: description: "This type provides information about added, deleted, modified and temporary virtual storage resources. It shall comply with the provisions in table 5.5.3.15-1.\nNOTE:\tThe \"resourceDefinitionId\" attribute provides information to the API consumer (i.e. the NFVO) to \n assist in correlating the resource changes performed during the LCM operation with the granted \n resources in a specific Grant exchange, which is identified by the \"grantId\" available in the \n \"Individual VNF lifecycle management operation occurrence\" and the \"id\" in the \"Individual Grant\".\n" type: object required: - id - virtualStorageDescId - changeType - storageResource properties: id: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string virtualStorageDescId: description: | An identifier that is unique within a VNF descriptor. type: string vnfdId: description: > An identifier with the intention of being globally unique. type: string changeType: description: > Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists. type: string enum: - ADDED - REMOVED - MODIFIED - TEMPORARY storageResource: required: - resourceId type: object description: > This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM. properties: vimConnectionId: description: > An identifier with the intention of being globally unique. type: string resourceProviderId: description: > An identifier with the intention of being globally unique. type: string resourceId: description: > An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance. type: string vimLevelResourceType: description: > The value set of the "vimLevelResourceType" attribute is within the scope of the VIM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2 in SOL003). type: string resourceDefinitionId: description: > An identifier that is unique within a limited local scope other than above listed identifiers, such as within a complex data structure or within a request-response pair. Representation: string of variable length. type: string zoneId: description: > An identifier with the intention of being globally unique. type: string metadata: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object changedInfo: description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource. The attributes that can be included consist of those requested to be modified explicitly in the \"VnfInfoModificationRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly e.g. when modifying the referenced VNF package. The \"VnfInfoModifications\" data type shall comply with the provisions defined in table 5.5.2.12a-1.\nNOTE:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) \n was modified implicitly following a request to modify the \"vnfdId\" attribute, by \n copying the value of this attribute from the VNFD in the VNF Package identified by \n the \"vnfdId\" attribute.\n" type: object properties: vnfInstanceName: description: | A string defined in IETF RFC 8259. type: string vnfInstanceDescription: description: | A string defined in IETF RFC 8259. type: string vnfConfigurableProperties: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object metadata: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object extensions: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object vimConnectionInfo: description: > If present, this attribute signals modifications the "vimConnectionInfo" attribute array in "VnfInstance". type: object additionalProperties: description: "This type represents parameters to connect to a VIM for managing the resources of a VNF instance. * NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM is provided through a secure connection over\n HTTP Secure (HTTP over SSL/TLS), and the connection might also be established through a VPN\n (for example TLS-based VPN tunnelling) for site-to-site connection, the \"accessInfo\" JSON data\n structure, and the sensitive data related information (\"username\"/\"password\" as required properties\n for authentication purpose), will be transmitted as plain text through a TLS tunnel without additional\n encoding/encryption before transmitting it, making the sensitive data visible to the endpoint.\n The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM.\n" type: object required: - vimType properties: vimId: description: > An identifier with the intention of being globally unique. type: string vimType: description: > Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the "interfaceInfo" and "accessInfo" attributes, based on the type of the VIM. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM types. The structure of the registry is defined in Annex C of SOL003. type: string interfaceInfo: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object accessInfo: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object extra: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object vnfdId: description: | An identifier with the intention of being globally unique. type: string vnfProvider: description: | A string defined in IETF RFC 8259. type: string vnfProductName: description: | A string defined in IETF RFC 8259. type: string vnfSoftwareVersion: description: | A version. type: string vnfdVersion: description: | A version. type: string affectedVipCps: description: > Information about virtual IP CP instances that were affected during the execution of the lifecycle management operation, if this notification represents the result of a lifecycle management operation occurrence. Shall be present if the "notificationStatus" is set to "RESULT", the "verbosity" attribute is set to "FULL" and the operation has made any changes to the VIP CP instances of the VNF instance. Shall be absent otherwise. Only information about VIP CP instances that have been added, deleted or modified shall be provided. type: array items: description: > This type provides information about added, deleted and modified virtual IP CP instances. type: object required: - cpInstanceId - cpdId - changeType properties: cpInstanceId: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string cpdId: description: | An identifier that is unique within a VNF descriptor. type: string vnfdId: description: > An identifier with the intention of being globally unique. type: string changeType: description: "Signals the type of change. Permitted values: -\tADDED -\tREMOVED -\tMODIFIED\n" type: string enum: - ADDED - REMOVED - MODIFIED changedExtConnectivity: description: > Information about changed external connectivity, if this notification represents the result of a lifecycle operation occurrence. Shall be present if the "notificationStatus" is set to "RESULT", the "verbosity" attribute is set to "FULL" and the operation has made any changes to the external connectivity of the VNF instance. Shall be absent otherwise. Only information about external VL instances that have been added or modified shall be provided. type: array items: description: "This type represents information about an external VL. It shall comply with the provisions defined in table 5.5.3.2-1.\nNOTE:\tThis attribute reflects the current configuration information that has resulted from merging into this attribute \n the \"VnfExtCpData\" information which was passed as part of the \"ExtVirtualLinkData\" structure in the input of the \n most recent VNF LCM operation such as \"InstantiateVnfRequest\", \"ChangeExtVnfConnectivityRequest\", \"ChangeVnfFlavourRequest\" \n or \"ChangeCurrentVnfPkgRequest\", or in the Grant response. If applying such change results in an empty list of \n \"currentVnfExtCpData\" structure instances, the affected instance of \"ExtVirtualLinkInfo\" shall be removed from its \n parent data structure.\n" type: object required: - id - resourceHandle - currentVnfExtCpData properties: id: description: > An identifier with the intention of being globally unique. type: string resourceHandle: required: - resourceId type: object description: > This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM. properties: vimConnectionId: description: > An identifier with the intention of being globally unique. type: string resourceProviderId: description: > An identifier with the intention of being globally unique. type: string resourceId: description: > An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance. type: string vimLevelResourceType: description: > The value set of the "vimLevelResourceType" attribute is within the scope of the VIM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2 in SOL003). type: string extLinkPorts: description: | Link ports of this VL. type: array items: description: "This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to an NS VL. It shall comply with the provisions defined in table 5.5.3.9-1.\nNOTE 1:\tThe use cases UC#4 and UC#5 in clause A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. NOTE 2:\tThe value of \"trunkResourceId\" is scoped by the value of \"vimConnectionId\" in the \"resourceHandle\" attribute.\n" type: object required: - id - resourceHandle properties: id: description: > An identifier with the intention of being globally unique. type: string resourceHandle: required: - resourceId type: object description: > This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM. properties: vimConnectionId: description: > An identifier with the intention of being globally unique. type: string resourceProviderId: description: > An identifier with the intention of being globally unique. type: string resourceId: description: > An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance. type: string vimLevelResourceType: description: > The value set of the "vimLevelResourceType" attribute is within the scope of the VIM or the resource provider and can be used as information that complements the ResourceHandle. This value set is different from the value set of the "type" attribute in the ResourceDefinition (refer to clause 9.5.3.2 in SOL003). type: string cpInstanceId: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string secondaryCpInstanceId: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string trunkResourceId: description: > An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance. type: string currentVnfExtCpData: description: > Allows the API consumer to read the current CP configuration information for the connection of external CPs to the external virtual link. See note. type: array items: description: "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or \n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a \n cpConfig map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\"\n or \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the\n related \"cpConfig\" map entries to a new \"extCpData\" structure.\n" type: object required: - cpdId properties: cpdId: description: > An identifier that is unique within a VNF descriptor. type: string cpConfig: description: > Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type "IdentifierInVnf" and is managed by the API consumer. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3 and 4. type: object additionalProperties: description: > This type represents an externally provided link port or network address information per instance of an external connection point. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the external VL. In a link port is not provided, the VNFM shall create a link port on the external VL, and use that link port to connect the external CP to the external VL. * NOTE: The following conditions apply to the attributes "linkPortId" and "cpProtocolData": 1) Void. 2) At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for an external CP instance representing a subport that is to be created, or an external CP instance that is to be created by creating the corresponding VNFC or VNF instance during the current or a subsequent LCM operation, or for an existing external CP instance that is to be re-configured or added to a particular external virtual link. 3) If the "linkPortId" attribute is absent, the VNFM shall create a link port. 4) If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a pre created link port, and the VNFM can use means outside the scope of the present document to obtain the pre-configured address information for the connection point from the resource representing the link port. 5) If both "cpProtocolData" and "linkportId" are provided, the API consumer shall ensure that the cpProtocolData can be used with the pre-created link port referenced by "linkPortId". anyOf: - required: - linkPortId - required: - cpProtocolData type: object properties: parentCpConfigId: description: > An identifier that is unique for the respective type within a VNF instance, but may not be globally unique. type: string linkPortId: description: > An identifier with the intention of being globally unique. type: string createExtLinkPort: description: > Indicates to the VNFM the need to create a dedicated link port for the external CP. If set to True, the VNFM shall create a link port. If set to False, the VNFM shall not create a link port. This attribute is only applicable for external CP instances without a floating IP address that expose a VIP CP instance for which a dedicated IP address is allocated. It shall be present in that case and shall be absent otherwise. type: boolean cpProtocolData: description: > Parameters for configuring the network protocols on the link port that connects the CP to a VL. See note. type: array items: description: "This type represents network protocol data. * NOTE:\tThis attribute allows to signal the addition of further types of layer and protocol\n in future versions of the present document in a backwards-compatible way. In the current\n version of the present document, only IP over Ethernet is supported.\n" type: object required: - layerProtocol properties: layerProtocol: description: > Identifier of layer(s) and protocol(s). See note. type: string enum: - IP_OVER_ETHERNET ipOverEthernet: description: "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI’s transport technology.\n" type: object anyOf: - required: - macAddress - required: - ipAddresses oneOf: - required: - fixedAddresses - required: - numDynamicAddresses - required: - ipAddressRange properties: macAddress: description: > A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons. type: string format: MAC segmentationType: description: "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n" type: string enum: - VLAN - INHERIT segmentationId: description: > Identification of the network segment to which the CP instance connects to. See note 3 and note 4. type: string ipAddresses: description: > List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned. See note 1. type: array items: type: object required: - type properties: type: description: > The type of the IP addresses. Permitted values: IPV4, IPV6. type: string enum: - IPV4 - IPV6 fixedAddresses: description: > Fixed addresses to assign (from the subnet defined by "subnetId" if provided). See note 2. type: array items: description: > An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons. type: string format: IP numDynamicAddresses: description: > Number of dynamic addresses to assign (from the subnet defined by "subnetId" if provided). See note 2. type: integer addressRange: description: > An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2. type: object required: - minAddress - maxAddress properties: minAddress: description: > An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons. type: string format: IP maxAddress: description: > An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons. type: string format: IP subnetId: description: > An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance. type: string modificationsTriggeredByVnfPkgChange: description: "This type represents attribute modifications that were performed on an \"Individual VNF instance\" resource when changing the current VNF package. The attributes that can be included consist of those requested to be modified explicitly in the \"ChangeCurrentVnfPkgRequest\" data structure, and additional attributes of the \"VnfInstance\" data structure that were modified implicitly during the operation. The \"ModificationsTriggeredByVnfPkgChange\" data type shall comply with the provisions defined in table 5.5.3.21-1.\nNOTE 1:\tThis attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value \n of the attribute at the start of the \"Change current VNF package\" operation and the value of the attribute \n at its completion.\nNOTE 2:\tIf present, this attribute (which depends on the value of the \"vnfdId\" attribute) was modified implicitly \n during the related operation and contains a copy of the value of the related attribute from the VNFD in the \n VNF Package identified by the \"vnfdId\" attribute.\n" type: object properties: vnfConfigurableProperties: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object metadata: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object extensions: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object vnfdId: description: | An identifier with the intention of being globally unique. type: string vnfProvider: description: > If present, this attribute signals the new value of the "vnfProvider" attribute in "VnfInstance". See note 2. type: string vnfProductName: description: > If present, this attribute signals the new value of the "vnfProductName" attribute in "VnfInstance". See note 2. type: string vnfSoftwareVersion: description: | A version. type: string vnfdVersion: description: | A version. type: string vimConnectionInfo: description: > If present, this attribute signals the changes to VIM connection info that were passed in the related "ChangeCurrentVnfPkgRequest" structure. The provisions for sensitive information defined in clause 4.4.1.6 apply. type: object additionalProperties: description: "This type represents parameters to connect to a VIM for managing the resources of a VNF instance. * NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM is provided through a secure connection over\n HTTP Secure (HTTP over SSL/TLS), and the connection might also be established through a VPN\n (for example TLS-based VPN tunnelling) for site-to-site connection, the \"accessInfo\" JSON data\n structure, and the sensitive data related information (\"username\"/\"password\" as required properties\n for authentication purpose), will be transmitted as plain text through a TLS tunnel without additional\n encoding/encryption before transmitting it, making the sensitive data visible to the endpoint.\n The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM.\n" type: object required: - vimType properties: vimId: description: > An identifier with the intention of being globally unique. type: string vimType: description: > Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the "interfaceInfo" and "accessInfo" attributes, based on the type of the VIM. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM types. The structure of the registry is defined in Annex C of SOL003. type: string interfaceInfo: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object accessInfo: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object extra: description: > This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type. type: object error: description: > The definition of the general "ProblemDetails" data structure from IETF RFC 7807 is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807, the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807. type: object required: - status - detail properties: type: description: > A URI reference according to IETF RFC 3986 that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank". type: string format: URI title: description: > A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4). type: string status: description: > The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem. type: integer detail: description: > A human-readable explanation specific to this occurrence of the problem. type: string instance: description: > A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced. type: string format: URI _links: description: > This type represents the links to resources that a notification can contain. type: object required: - vnfInstance - subscription properties: vnfInstance: description: > This type represents a link to a resource in a notification, using an absolute or relative URI. type: object required: - href properties: href: description: | String formatted according to IETF RFC 3986. type: string subscription: description: > This type represents a link to a resource in a notification, using an absolute or relative URI. type: object required: - href properties: href: description: | String formatted according to IETF RFC 3986. type: string vnfLcmOpOcc: description: > This type represents a link to a resource in a notification, using an absolute or relative URI. type: object required: - href properties: href: description: | String formatted according to IETF RFC 3986. type: string required: true VnfIdentifierCreationNotification: description: > A notification about the creation of a VNF identifier and the related "Individual VNF instance" resource. content: application/json: schema: description: > This type represents a VNF identifier creation notification, which informs the receiver of the creation of a new "Individual VNF instance" resource and the associated VNF instance identifier. This notification shall be triggered by the VNFM when it has created an "Individual VNF instance" resource and the associated VNF instance identifier. type: object required: - id - notificationType - subscriptionId - timeStamp - vnfInstanceId - _links properties: id: description: | An identifier with the intention of being globally unique. type: string notificationType: description: > Discriminator for the different notification types. Shall be set to "VnfIdentifierCreationNotification" for this notification type. type: string enum: - VnfIdentifierCreationNotification subscriptionId: description: | An identifier with the intention of being globally unique. type: string timeStamp: description: > Date-time stamp. Representation: String formatted according to IETF RFC 3339. type: string format: date-time vnfInstanceId: description: | An identifier with the intention of being globally unique. type: string _links: description: > This type represents the links to resources that a notification can contain. type: object required: - vnfInstance - subscription properties: vnfInstance: description: > This type represents a link to a resource in a notification, using an absolute or relative URI. type: object required: - href properties: href: description: | String formatted according to IETF RFC 3986. type: string subscription: description: > This type represents a link to a resource in a notification, using an absolute or relative URI. type: object required: - href properties: href: description: | String formatted according to IETF RFC 3986. type: string vnfLcmOpOcc: description: > This type represents a link to a resource in a notification, using an absolute or relative URI. type: object required: - href properties: href: description: | String formatted according to IETF RFC 3986. type: string required: true VnfIdentifierDeletionNotification: description: > A notification about the deletion of a VNF identifier and the related "Individual VNF instance" resource. content: application/json: schema: description: > This type represents a VNF identifier deletion notification, which informs the receiver of the deletion of a new "Individual VNF instance" resource and the associated VNF instance identifier. This notification shall be triggered by the VNFM when it has deleted an "Individual VNF instance" resource and the associated VNF instance identifier. type: object required: - id - notificationType - subscriptionId - timeStamp - vnfInstanceId - _links properties: id: description: | An identifier with the intention of being globally unique. type: string notificationType: description: > Discriminator for the different notification types. Shall be set to "VnfIdentifierDeletionNotification" for this notification type. type: string enum: - VnfIdentifierDeletionNotification subscriptionId: description: | An identifier with the intention of being globally unique. type: string timeStamp: description: > Date-time stamp. Representation: String formatted according to IETF RFC 3339. type: string format: date-time vnfInstanceId: description: | An identifier with the intention of being globally unique. type: string _links: description: > This type represents the links to resources that a notification can contain. type: object required: - vnfInstance - subscription properties: vnfInstance: description: > This type represents a link to a resource in a notification, using an absolute or relative URI. type: object required: - href properties: href: description: | String formatted according to IETF RFC 3986. type: string subscription: description: > This type represents a link to a resource in a notification, using an absolute or relative URI. type: object required: - href properties: href: description: | String formatted according to IETF RFC 3986. type: string vnfLcmOpOcc: description: > This type represents a link to a resource in a notification, using an absolute or relative URI. type: object required: - href properties: href: description: | String formatted according to IETF RFC 3986. type: string required: true responses: VnfLcmOperationOccurrenceNotification.Post.204: description: | 204 NO CONTENT Shall be returned when the notification has been delivered successfully. headers: WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. style: simple explode: false schema: type: string Version: description: The used API version. style: simple explode: false schema: type: string VnfLcmOperationOccurrenceNotification.Get.204: description: > 204 NO CONTENT Shall be returned to indicate that the notification endpoint has been tested successfully. The response body shall be empty. headers: WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. style: simple explode: false schema: type: string Version: description: The used API version. style: simple explode: false schema: type: string VnfIdentifierCreationNotification.Post.204: description: | 204 NO CONTENT Shall be returned when the notification has been delivered successfully. headers: WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. style: simple explode: false schema: type: string Version: description: The used API version. style: simple explode: false schema: type: string VnfIdentifierCreationNotification.Get.204: description: > 204 NO CONTENT Shall be returned to indicate that the notification endpoint has been tested successfully. The response body shall be empty. headers: WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. style: simple explode: false schema: type: string Version: description: The used API version. style: simple explode: false schema: type: string VnfIdentifierDeletionNotification.Post.204: description: | 204 NO CONTENT Shall be returned when the notification has been delivered successfully. headers: WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. style: simple explode: false schema: type: string Version: description: The used API version. style: simple explode: false schema: type: string VnfIdentifierDeletionNotification.Get.204: description: > 204 NO CONTENT Shall be returned to indicate that the notification endpoint has been tested successfully. The response body shall be empty. headers: WWW-Authenticate: description: > Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token. style: simple explode: false schema: type: string Version: description: The used API version. style: simple explode: false schema: type: string