SOL003-VNFLifecycleManagement-API.json

                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "401": {
            "description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "403": {
            "description": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided.  It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "404": {
            "description": "Not Found\nError: The API producer did not find a current representation for the target resource or is not willing to disclose that one exists. Specifically in case of this task resource, the  response code 404 shall also be returned if the task is not supported for the VNF LCM operation occurrence represented by the parent resource, which means that the task resource consequently does not exist.  In this case, the response body shall be present, and shall contain a ProblemDetails structure, in which the \"detail\" attribute shall convey more information about the error.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "405": {
            "description": "Not Found\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "406": {
            "description": "Not Acceptable\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.        \n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "409": {
            "description": "The operation cannot be executed currently, due to a conflict with the state of the VNF instance resource. Typically, this is due to the fact that the VNF instance resource is not in FAILED_TEMP state, or another error handling action is starting, such as rollback or fail. The response body shall contain a ProblemDetails structure, in which the \"detail\" attribute should convey more information about the error.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "500": {
            "description": "Internal Server Error\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "503": {
            "description": "Service Unavailable\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          }
        }
      }
    },
    "/vnf_lcm_op_occs/{vnfLcmOpOccId}/cancel": {
      "parameters": [
        {
          "name": "vnfLcmOpOccId",
          "description": "Identifier of a VNF lifecycle management operation occurrence to be be cancelled. This identifier can be retrieved from the resource referenced by the \"Location\" HTTP header in the response to a PATCH or POST request triggering a VNF LCM operation. It can also be retrieved from the \"vnfLcmOpOccId\" attribute in the VnfLcmOperationOccurrenceNotification.\n",
          "in": "path",
          "required": true,
          "type": "string"
        }
      ],
      "post": {
        "description": "The POST method initiates cancelling an ongoing VNF lifecycle operation while it is being executed or rolled back, i.e. the related \"VNF LCM operation occurrence\" is either in \"PROCESSING\" or \"ROLLING_BACK\" state.\n",
        "parameters": [
          {
            "name": "Authorization",
            "description": "The authorization token for the request. Reference: IETF RFC 7235\n",
            "in": "header",
            "required": false,
            "type": "string"
          }
        ],
        "responses": {
          "202": {
            "description": "Accepted\nThe request was accepted for processing, but processing has not been completed. The response shall have an empty payload body.\n",
            "headers": {
              "Location": {
                "description": "The resource URI of the created VNF instance",
                "type": "string",
                "format": "url"
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            }
          },
          "400": {
            "description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided, and should include in the \"detail\" attribute more information about the source of the problem. If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond with this response code.The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "401": {
            "description": "Unauthorized\nIf the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "403": {
            "description": "Forbidden\nIf the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure shall be provided.  It should include in the \"detail\" attribute information about the source of the problem, and may indicate how to solve it.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "404": {
            "description": "Not Found\nError: The API producer did not find a current representation for the target resource or is not willing to disclose that one exists. Specifically in case of this task resource, the  response code 404 shall also be returned if the task is not supported for the VNF LCM operation occurrence represented by the parent resource, which means that the task resource consequently does not exist.  In this case, the response body shall be present, and shall contain a ProblemDetails structure, in which the \"detail\" attribute shall convey more information about the error.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "405": {
            "description": "Not Found\nIf the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "406": {
            "description": "Not Acceptable\nIf the \"Accept\" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.        \n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "409": {
            "description": "Conflict\nThe operation cannot be executed currently, due to a conflict with the state of the VNF LCM operation occurrence resource. Typically, this is due to the fact that the operation occurrence is not in STARTING, PROCESSING or ROLLING_BACK state. The response body shall contain a ProblemDetails structure, in which the \"detail\" attribute shall convey more information about the error.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              },
              "WWW-Authenticate": {
                "description": "Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n",
                "type": "string",
                "maximum": 1,
                "minimum": 0
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "500": {
            "description": "Internal Server Error\nIf there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          },
          "503": {
            "description": "Service Unavailable\nIf the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
            "headers": {
              "Content-Type": {
                "description": "The MIME type of the body of the response.",
                "type": "string",
                "maximum": 1,
                "minimum": 1
              }
            },
            "schema": {
              "description": "The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n",
              "type": "object",
              "required": [
                "status",
                "detail"
              ],
              "properties": {
                "type": {
                  "description": "A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n",
                  "type": "string",
                  "format": "URI"
                },
                "title": {
                  "description": "A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n",
                  "type": "string"
                },
                "status": {
                  "description": "The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n",
                  "type": "integer"
                },
                "detail": {
                  "description": "A human-readable explanation specific to this occurrence of the problem.\n",
                  "type": "string"
                },
                "instance": {
                  "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
                  "type": "string",
                  "format": "URI"
                }
              }
            }
          }
        }
      }
    },
    "/subscriptions": {
      "post": {
        "description": "Subscribe\n\nThe POST method creates a new subscription. Creation of two subscription resources with the same callbackURI and the same filter can result in performance degradation and will provide duplicates of notifications to the NFVO, and might make sense only in very rare use cases. Consequently, the VNFM may either allow creating a subscription resource if another subscription resource with the same filter and callbackUri already exists (in which case it shall return the “201 Created” response code), or may decide to not create a duplicate subscription resource (in which case it shall return a “303 See Other” response code referencing the existing subscription resource with the same filter and callbackUri).\n",
        "parameters": [
          {
            "name": "LccnSubscriptionRequest",
            "description": "Details of the subscription to be created.\n",
            "in": "body",
            "required": true,
            "schema": {
              "description": "This type represents a subscription request related to notifications about VNF lifecycle changes.\n",
              "type": "object",
              "required": [
                "callbackUri"
              ],
              "properties": {
                "filter": {
                  "description": "This type represents a subscription filter related to notifications about VNF lifecycle changes. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n",
                  "type": "object",
                  "properties": {
                    "vnfInstanceSubscriptionFilter": {
                      "description": "This type represents subscription filter criteria to match VNF instances.\n",
                      "type": "object",
                      "properties": {
                        "vnfdIds": {
                          "description": "If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
                          "type": "array",
                          "items": {
                            "description": "An identifier with the intention of being globally unique.\n",
                            "type": "string"
                          }
                        },
                        "vnfProductsFromProviders": {
                          "description": "If present, match VNF instances that belong to VNF products from certain providers. The attributes \"vnfdIds\" and \"vnfProductsFromProviders\" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
                          "type": "array",
                          "items": {
                            "type": "object",
                            "required": [
                              "vnfProvider"
                            ],
                            "properties": {
                              "vnfProvider": {
                                "description": "Name of the VNF provider to match.\n",
                                "type": "string"
                              },
                              "vnfProducts": {
                                "description": "If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.\n",
                                "type": "array",
                                "items": {
                                  "type": "object",
                                  "required": [
                                    "vnfProductName"
                                  ],
                                  "properties": {
                                    "vnfProductName": {
                                      "description": "Name of the VNF product to match.\n",
                                      "type": "string"
                                    },
                                    "versions": {
                                      "description": "If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.\n",
                                      "type": "array",
                                      "items": {
                                        "type": "object",
                                        "required": [
                                          "vnfSoftwareVersion"
                                        ],
                                        "properties": {
                                          "vnfSoftwareVersion": {
                                            "description": "A version.\n",
                                            "type": "string"
                                          },
                                          "vnfdVersions": {
                                            "description": "If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n",
                                            "type": "array",
                                            "items": {
                                              "description": "A version.\n",
                                              "type": "string"
                                            }
                                          }
                                        }
                                      }
                                    }
                                  }
                                }
                              }
                            }
                          }
                        },
                        "vnfInstanceIds": {
                          "description": "If present, match VNF instances with an instance identifier listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
                          "type": "array",
                          "items": {
                            "description": "An identifier with the intention of being globally unique.\n",
                            "type": "string"
                          }
                        },
                        "vnfInstanceNames": {
                          "description": "If present, match VNF instances with a VNF Instance Name listed in this attribute. The attributes \"vnfInstanceIds\" and \"vnfInstanceNames\" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.\n",
                          "type": "array",
                          "items": {
                            "type": "string"
                          }
                        }
                      }
                    },
                    "notificationTypes": {
                      "description": "Match particular notification types. Permitted values: * VnfLcmOperationOccurrenceNotification * VnfIdentifierCreationNotification * VnfIdentifierDeletionNotification The permitted values of the \"notificationTypes\" attribute are spelled exactly as the names of the notification types to facilitate automated code generation systems.\n",
                      "type": "array",
                      "items": {
                        "type": "string",
                        "enum": [
                          "VnfLcmOperationOccurrenceNotification",
                          "VnfIdentifierCreationNotification",
                          "VnfIdentifierDeletionNotification"
                        ]
                      }
                    },
                    "operationTypes": {
                      "description": "Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n",
                      "type": "array",
                      "items": {
                        "description": "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.     \n",
                        "type": "string",
                        "enum": [
                          "INSTANTIATE",
                          "SCALE",
                          "SCALE_TO_LEVEL",
                          "CHANGE_FLAVOUR",
                          "TERMINATE",
                          "HEAL",
                          "OPERATE",
                          "CHANGE_EXT_CONN",
                          "MODIFY_INFO"
                        ]
                      }
                    },
                    "operationStates": {
                      "description": "Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the \"notificationTypes\" attribute contains the value \"VnfLcmOperationOccurrenceNotification\", and shall be absent otherwise.\n",
                      "type": "array",
                      "items": {
                        "description": "Value | Description ------|------------ STARTING | The LCM operation is starting. PROCESSING | The LCM operation is currently in execution. COMPLETED | he LCM operation has been completed successfully. FAILED_TEMP | The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED | The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK | The LCM operation is currently being rolled back. ROLLED_BACK | The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.\n",
                        "type": "string",
                        "enum": [
                          "STARTING",
                          "PROCESSING",
                          "COMPLETED",
                          "FAILED_TEMP",
                          "FAILED",
                          "ROLLING_BACK",
                          "ROLLED_BACK"
                        ]
                      }
                    }
                  }
                },
                "callbackUri": {
                  "description": "String formatted according to IETF RFC 3986.\n",
                  "type": "string"
                },
                "authentication": {
                  "type": "object",
                  "required": [
                    "authType"
                  ],
                  "properties": {
                    "authType": {
                      "description": "Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use\n  HTTP Basic authentication with the client credentials. \n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the\n  notification endpoint, use an OAuth 2.0 Bearer token, obtained\n  using the client credentials grant type.\n* TLS_CERT: Every HTTP request to the notification endpoint is sent\n  over a mutually authenticated TLS session, i.e. not only the\n  server is authenticated, but also the client is authenticated\n  during the TLS tunnel setup.\n",
                      "type": "array",
                      "items": {
                        "type": "string",
                        "enum": [
                          "BASIC",
                          "OAUTH2_CLIENT_CREDENTIALS",
                          "TLS_CERT"
                        ]
                      }
                    },
                    "paramsBasic": {
                      "description": "Parameters for authentication/authorization using BASIC. Shall be present if authType is \"BASIC\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n",
                      "type": "object",
                      "properties": {
                        "userName": {
                          "description": "Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n",
                          "type": "string"
                        },