{"swagger":"2.0","info":{"version":"2.4.1","title":"DRAFT - SOL005 - VNF Package Management Interface","description":"DRAFT - SOL005 - VNF Package Management Interface IMPORTANT: Please note that this file might be not aligned to the current version of the ETSI Group Specification it refers to and has not been approved by the ETSI NFV ISG. In case of discrepancies the published ETSI Group Specification takes precedence. Please report bugs to https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis\n","license":{"name":"ETSI Forge copyright notice","url":"https://forge.etsi.org/etsi-forge-copyright-notice.txt"},"contact":{"name":"NFV-SOL WG"}},"externalDocs":{"description":"ETSI GS NFV-SOL 005 V2.4.1","url":"http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/005/02.04.01_60/gs_NFV-SOL005v020401p.pdf"},"basePath":"/vnfpkgm/v1","schemes":["https"],"consumes":["application/json"],"produces":["application/json"],"paths":{"/vnf_packages":{"get":{"summary":"VNF packages","description":"\"The GET method queries the information of the VNF packages matching the filter.\n This method shall follow the provisions specified in the \n Tables 9.4.2.3.2-1 and 9.4.2.3.2-2 for URI query parameters,\n request and response data structures, and response codes.\"\n","parameters":[{"name":"filter","in":"query","required":false,"type":"string","description":"\"Attribute-based filtering parameters according to clause 4.3.2. The NFVO shall support receiving filtering parameters as part of the URI query string. The OSS/BSS may supply filtering parameters. All attribute names that appear in the VnfPkgInfo and in data types referenced from it shall be supported in attribute-based filtering parameters.\"\n"},{"name":"all_fields","in":"query","required":false,"type":"string","description":"\"Include all complex attributes in the response. See clause 4.3.3 for details. The NFVO shall support this parameter.\"\n"},{"name":"fields","in":"query","required":false,"type":"string","description":"\"Complex attributes to be included into the response. See clause 4.3.3 for details. The NFVO should support this parameter.\"\n"},{"name":"exclude_fields","in":"query","required":false,"type":"string","description":"\"Complex attributes to be excluded from the response. See clause 4.3.3 for details. The NFVO should support this parameter.\"\n"},{"name":"exclude_default","in":"query","required":false,"type":"string","description":"\"Indicates to exclude the following complex attributes from the response. See clause 4.3.3 for details. The NFVO shall support this parameter. The following attributes shall be excluded from the VnfPkgInfo structure in the response body if this parameter is provided, or none of the parameters \"all_fields,\" \"fields\", \"exclude_fields\", \"exclude_default\" are provided: - softwareImages - additionalArtifacts - userDefinedData - checksum.\"\n"},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"}],"responses":{"200":{"description":"\"Status 200\"\n","schema":{"type":"array","description":"\"Information of the selected VNF packages.\"\n","items":{"type":"object","required":["id","onboardingState","operationalState","usageState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF package and the VNFD. This information is copied from the VNFD.  It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF product.Invariant for the VNF product lifetime.  This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfSoftwareVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfdVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"checksum":{"description":"This type represents the checksum of a VNF package or an artifact file.\n","required":["algorithm","hash"],"type":"object","properties":{"algorithm":{"description":"Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004 [5]. For example, SHA-256, SHA-512.\n","type":"string"},"hash":{"description":"The hexadecimal value of the checksum.\n","type":"string"}}},"softwareImages":{"description":"Information about VNF package artifacts that are software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n","type":"array","items":{"description":"This type represents an artifact contained in a VNF package which represents a software image.\n","required":["id","name","provider","version","checksum","containerFormat","diskFormat","createdAt","minDisk","minRam","size","imagePath"],"type":"object","properties":{"id":{"description":"Identifier of the software image.\n","type":"string"},"name":{"description":"Name of the software image.\n","type":"string"},"provider":{"description":"Provider of the software image.\n","type":"string"},"version":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"checksum":{"description":"This type represents the checksum of a VNF package or an artifact file.\n","required":["algorithm","hash"],"type":"object","properties":{"algorithm":{"description":"Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004 [5]. For example, SHA-256, SHA-512.\n","type":"string"},"hash":{"description":"The hexadecimal value of the checksum.\n","type":"string"}}},"containerFormat":{"description":"Container format indicates whether the software image is in a file format that also contains metadata about the actual software. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format\n","type":"string","enum":["AKI","AMI","ARI","BARE","DOCKER","OVA","OVF"]},"diskFormat":{"description":"Disk format of a software image is the format of the underlying disk image. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - ISO: an archive format for the data contents of an optical disc, such as CD-ROM - QCOW2: a common disk image format, which can expand dynamically and supports copy on write - RAW: an unstructured disk image format - VDI: a common disk image format - VHD: a common disk image format - VHDX: enhanced version of VHD format - VMDK: a common disk image format\n","type":"string","enum":["AKI","AMI","ARI","ISO","QCOW2","RAW","VDI","VHD","VHDX","VMDK"]},"createdAt":{"description":"Date-time stamp.  Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"minDisk":{"description":"The minimal disk for this software image in bytes.\n","type":"integer"},"minRam":{"description":"The minimal RAM for this software image in bytes.\n","type":"integer"},"size":{"description":"Size of this software image in bytes.\n","type":"integer"},"userMetadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions  defined in clause 4 of IETF RFC 7159.\n","type":"object"},"imagePath":{"description":"Path in the VNF package, which identifies the image artifact and also allows to access a copy of the image artifact.\n","type":"string"}}}}}}}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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"}}}}}},"post":{"summary":"VNF packages","description":"\"The POST method creates a new individual VNF package resource.\"\n","parameters":[{"name":"CreateVnfPkgInfoRequest","description":"\"IndividualVNF package resource creation parameters, as defined in clause 9.5.2.2\"\n","in":"body","required":true,"schema":{"type":"object","properties":{"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions  defined in clause 4 of IETF RFC 7159.\n","type":"object"}},"description":"\"This type represents the request parameters for creating a new individual VNF package resource. It shall comply with the provisions defined in Table 9.5.2.2-1.\"\n"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"}],"responses":{"201":{"description":"\"Status 201 - Created\"\n\n\"An individual VNF package resource has been created successfully. The response body shall contain a representation of the new individual VNF package resource, as defined in clause 9.5.2.4. The HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the individual VNF package resource.\"\n","schema":{"type":"object","required":["id","onboardingState","operationalState","usageState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF package and the VNFD. This information is copied from the VNFD.  It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF product.Invariant for the VNF product lifetime.  This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfSoftwareVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfdVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"checksum":{"description":"This type represents the checksum of a VNF package or an artifact file.\n","required":["algorithm","hash"],"type":"object","properties":{"algorithm":{"description":"Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004 [5]. For example, SHA-256, SHA-512.\n","type":"string"},"hash":{"description":"The hexadecimal value of the checksum.\n","type":"string"}}},"softwareImages":{"description":"Information about VNF package artifacts that are software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n","type":"array","items":{"description":"This type represents an artifact contained in a VNF package which represents a software image.\n","required":["id","name","provider","version","checksum","containerFormat","diskFormat","createdAt","minDisk","minRam","size","imagePath"],"type":"object","properties":{"id":{"description":"Identifier of the software image.\n","type":"string"},"name":{"description":"Name of the software image.\n","type":"string"},"provider":{"description":"Provider of the software image.\n","type":"string"},"version":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"checksum":{"description":"This type represents the checksum of a VNF package or an artifact file.\n","required":["algorithm","hash"],"type":"object","properties":{"algorithm":{"description":"Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004 [5]. For example, SHA-256, SHA-512.\n","type":"string"},"hash":{"description":"The hexadecimal value of the checksum.\n","type":"string"}}},"containerFormat":{"description":"Container format indicates whether the software image is in a file format that also contains metadata about the actual software. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format\n","type":"string","enum":["AKI","AMI","ARI","BARE","DOCKER","OVA","OVF"]},"diskFormat":{"description":"Disk format of a software image is the format of the underlying disk image. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - ISO: an archive format for the data contents of an optical disc, such as CD-ROM - QCOW2: a common disk image format, which can expand dynamically and supports copy on write - RAW: an unstructured disk image format - VDI: a common disk image format - VHD: a common disk image format - VHDX: enhanced version of VHD format - VMDK: a common disk image format\n","type":"string","enum":["AKI","AMI","ARI","ISO","QCOW2","RAW","VDI","VHD","VHDX","VMDK"]},"createdAt":{"description":"Date-time stamp.  Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"minDisk":{"description":"The minimal disk for this software image in bytes.\n","type":"integer"},"minRam":{"description":"The minimal RAM for this software image in bytes.\n","type":"integer"},"size":{"description":"Size of this software image in bytes.\n","type":"integer"},"userMetadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions  defined in clause 4 of IETF RFC 7159.\n","type":"object"},"imagePath":{"description":"Path in the VNF package, which identifies the image artifact and also allows to access a copy of the image artifact.\n","type":"string"}}}}}},"headers":{"Location":{"type":"string","description":"\"The HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the new NS descriptor resource.\"\n"}}}}}},"/vnf_packages/{vnfPkgId}":{"get":{"summary":"Individual VNF package","description":"\"This resource represents an individual VNF package.  The client can use this resource to read information of the VNF package, update information of the VNF package, or delete a VNF package.\"\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"}],"responses":{"200":{"description":"\"200 OK\"\n\"Information of the VNF package.\"\n","schema":{"type":"object","required":["id","onboardingState","operationalState","usageState"],"properties":{"id":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfdId":{"description":"An identifier with the intention of being globally unique.\n","type":"string"},"vnfProvider":{"description":"Provider of the VNF package and the VNFD. This information is copied from the VNFD.  It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfProductName":{"description":"Name to identify the VNF product.Invariant for the VNF product lifetime.  This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfSoftwareVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfdVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"checksum":{"description":"This type represents the checksum of a VNF package or an artifact file.\n","required":["algorithm","hash"],"type":"object","properties":{"algorithm":{"description":"Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004 [5]. For example, SHA-256, SHA-512.\n","type":"string"},"hash":{"description":"The hexadecimal value of the checksum.\n","type":"string"}}},"softwareImages":{"description":"Information about VNF package artifacts that are software images. This attribute shall not be present before the VNF package content is on-boarded. Otherwise, this attribute shall be present unless it has been requested to be excluded per attribute selector.\n","type":"array","items":{"description":"This type represents an artifact contained in a VNF package which represents a software image.\n","required":["id","name","provider","version","checksum","containerFormat","diskFormat","createdAt","minDisk","minRam","size","imagePath"],"type":"object","properties":{"id":{"description":"Identifier of the software image.\n","type":"string"},"name":{"description":"Name of the software image.\n","type":"string"},"provider":{"description":"Provider of the software image.\n","type":"string"},"version":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"checksum":{"description":"This type represents the checksum of a VNF package or an artifact file.\n","required":["algorithm","hash"],"type":"object","properties":{"algorithm":{"description":"Name of the algorithm used to generate the checksum, as defined in ETSI GS NFV-SOL 004 [5]. For example, SHA-256, SHA-512.\n","type":"string"},"hash":{"description":"The hexadecimal value of the checksum.\n","type":"string"}}},"containerFormat":{"description":"Container format indicates whether the software image is in a file format that also contains metadata about the actual software. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - BARE: the image does not have a container or metadata envelope - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format\n","type":"string","enum":["AKI","AMI","ARI","BARE","DOCKER","OVA","OVF"]},"diskFormat":{"description":"Disk format of a software image is the format of the underlying disk image. Permitted values: - AKI: a kernel image format - AMI: a machine image format - ARI: a ramdisk image format - ISO: an archive format for the data contents of an optical disc, such as CD-ROM - QCOW2: a common disk image format, which can expand dynamically and supports copy on write - RAW: an unstructured disk image format - VDI: a common disk image format - VHD: a common disk image format - VHDX: enhanced version of VHD format - VMDK: a common disk image format\n","type":"string","enum":["AKI","AMI","ARI","ISO","QCOW2","RAW","VDI","VHD","VHDX","VMDK"]},"createdAt":{"description":"Date-time stamp.  Representation: String formatted according to IETF RFC 3339.\n","type":"string","format":"date-time"},"minDisk":{"description":"The minimal disk for this software image in bytes.\n","type":"integer"},"minRam":{"description":"The minimal RAM for this software image in bytes.\n","type":"integer"},"size":{"description":"Size of this software image in bytes.\n","type":"integer"},"userMetadata":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions  defined in clause 4 of IETF RFC 7159.\n","type":"object"},"imagePath":{"description":"Path in the VNF package, which identifies the image artifact and also allows to access a copy of the image artifact.\n","type":"string"}}}}}}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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"}}}}}},"delete":{"summary":"Individual VNF package","description":"\"The DELETE method deletes an individual NS descriptor resource.\n","parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"}],"responses":{"204":{"description":"\"204 No Content\" \"The operation has completed successfully. The response body shall be empty.\"\n","schema":{"type":"object","description":"\"The operation has completed successfully. The response body shall be empty.\"\n"}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\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\nError: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to any of the following scenarios: - Disable a VNF package resource of hich the operational state is not ENABLED - Enable a VNF package resource of which the operational state is not DISABLED 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"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}}}},"patch":{"summary":"Individual VNF package","description":"\"The PATCH method updates the information of a VNF package.\"\n\"This method shall follow the provisions specified in the  Tables 9.4.3.3.4-1 and 9.4.3.3.4-2 for URI query parameters, request and response data structures, and response codes.\"\n","parameters":[{"name":"VnfPkgInfoModifications","in":"body","required":true,"schema":{"type":"object","required":["VnfPkgInfoModifications"],"properties":{"NsdInfoModifications":{"description":"This type represents modifications to the information of a VNF package.  It shall comply with the provisions defined in Table 9.5.2.3-1.\n","properties":{"operationalState":{"type":"string","description":"\"The enumeration PackageOperationalStateType shall  comply with the provisions defined in Table 9.5.4.4-1.\" Acceptable values are: -ENABLED - The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances. -DISABLED - The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package is re-enabled).\n","enum":["ENABLED","DISABLED"]},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions  defined in clause 4 of IETF RFC 7159.\n","type":"object"}}}},"description":"\"Parameters for VNF package information modifications.\"\n"}},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"}],"responses":{"200":{"description":"\"200 OK.\"\n\"The operation was completed successfully. The response body shall contain attribute modifications for an \"Individual VNF package\" resource.\"\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":"This type represents modifications to the information of a VNF package.  It shall comply with the provisions defined in Table 9.5.2.3-1.\n","properties":{"operationalState":{"type":"string","description":"\"The enumeration PackageOperationalStateType shall  comply with the provisions defined in Table 9.5.4.4-1.\" Acceptable values are: -ENABLED - The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances. -DISABLED - The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package is re-enabled).\n","enum":["ENABLED","DISABLED"]},"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions  defined in clause 4 of IETF RFC 7159.\n","type":"object"}}}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\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\nError: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to any of the following scenarios: - Disable a VNF package resource of hich the operational state is not ENABLED - Enable a VNF package resource of which the operational state is not DISABLED 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"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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"}}}}}},"parameters":[{"name":"vnfPkgId","description":"\"Identifier of the VNF package. The identifier is allocated by the NFVO\".\n","in":"path","required":true,"type":"string"}]},"/vnf_packages/{vnfPkgId}/vnfd":{"parameters":[{"name":"vnfPkgId","description":"\"Identifier of the on-boarded VNF package. The identifier is allocated by the NFVO.\"\n","in":"path","type":"string","required":true}],"get":{"summary":"VNFD of an individual VNF package","description":"\"The GET method reads the content of the VNFD within a VNF package.\"\n\"The VNFD can be implemented as a single file or as a collection of multiple files. If the VNFD is implemented in the form of multiple files, a ZIP file embedding these files shall be returned. If the VNFD is implemented as a single file, either that file or a ZIP file embedding that file shall be returned. The selection of the format is controlled by the \"Accept\" HTTP header passed in the GET request. • If the \"Accept\" header contains only \"text/plain\" and the VNFD is implemented as a single file, the file shall be returned; otherwise, an error message shall be returned. • If the \"Accept\" header contains only \"application/zip\", the single file or the multiple files that make up the VNFD shall be returned embedded in a ZIP file. • If the \"Accept\" header contains both \"text/plain\" and \"application/zip\", it is up to the NFVO to choose the format to return for a single-file VNFD; for a multi-file VNFD, a ZIP file shall be returned. The default format of the ZIP file shall be the one specified in ETSI GS NFV-SOL 004 [5] where only the YAML files representing the VNFD, and information necessary to navigate the ZIP file and to identify the file that is the entry point for parsing the VNFD (such as TOSCA-meta or manifest files or naming conventions) are included. This method shall follow the provisions specified in the Tables 9.4.4.3.2-1 and 9.4.4.3.2-2 for URI query parameters, request and response data structures, and response codes.\"\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response.\n","in":"header","required":true,"type":"string","enum":["text/plain","application/zip"]},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"}],"responses":{"200":{"description":"OK\nOn success, the content of the VNFD is returned. The payload body shall contain a copy of the file representing the VNFD or a ZIP file that contains the file or multiple files representing the VNFD, as specified above. The \"Content-Type\" HTTP header shall be set according to the format of the returned file, i.e. to \"text/plain\" for a YAML file or to \"application/zip\" for a ZIP file.\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}}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\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":"Error: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to the fact that \"onboardingState\" of the VNF package has a value different from \"ONBOARDED\". The response body shall contain a ProblemDetails structure, in which the \"detail\" attribute shall convey more information about the error.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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_packages/{vnfPkgId}/package_content":{"get":{"summary":"VNF package content","description":"\"The GET method fetches the content of a VNF package identified  by the VNF package identifier allocated by the NFVO.\"\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response.\n","in":"header","required":true,"type":"string","enum":["text/plain","application/zip"]},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"},{"name":"Range","in":"header","required":false,"type":"string","description":"The request may contain a \"Range\" HTTP header to obtain single ange of bytes from the VNF package file. This can be used to ontinue an aborted transmission. \nIf the NFVO does not support range requests, it should return the whole file with a 200 OK response instead.\n"}],"responses":{"200":{"description":"OK\nOn success, a copy of the VNF package file is returned. The response body shall include a copy of the VNF package file. The \"Content-Type\" HTTP header shall be set according to the type of the file, i.e. to \"application/zip\" for a VNF Package as defined in ETSI GS NFV-SOL 004 [5].\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}}},"206":{"description":"Partial Content\nOn success, if the NFVO supports range requests, a single consecutive byte range from the content of the NSD file is returned. The response body shall contain the requested part of the NSD file. The \"Content-Range\" HTTP header shall be provided according to IETF RFC 7233 [23]. The \"Content-Type\" HTTP header shall be set as defined above for the \"200 OK\" response.\n","headers":{"Content-Range":{"type":"string"},"Content-Type":{"type":"string"}},"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"}}}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\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\nError: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to the fact that \"onboardingState\" of the VNF package has a value different from \"ONBOARDED\". The response body shall contain a ProblemDetails structure, in which the \"detail\" attribute shall convey more information about the error.\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"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the VNF package file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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"}}}}}},"put":{"summary":"VNF package content.","description":"\"The PUT method uploads the content of a VNF package.\"\n","consumes":["multipart/form-data"],"parameters":[{"in":"formData","name":"file","required":false,"type":"file","description":"The payload body contains a ZIP file that represents the VNF package. The \"Content-Type\" HTTP header shall be set according to the type of the file, i.e. to \"application/zip\" for a VNF Package as defined in ETSI GS NFV-SOL 004 [5].\n"}],"responses":{"202":{"description":"\"202 Accepted\"\n\"The VNF package was accepted for uploading, but the\n processing has not been completed. It is expected to\n take some time for processing.\n The response body shall be empty. See note.\"\n"},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\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\nError: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to the fact that the onboarding state of the VNF package resource is not CREATED . 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 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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"}}}}}},"parameters":[{"name":"vnfPkgId","in":"path","required":true,"type":"string"}]},"/vnf_packages/{vnfPkgId}/package_content/upload_from_uri":{"post":{"summary":"Upload VNF package from URI task.","description":"\"This task resource represents the \"Upload VNF package from URI\" operation. The client can use this resource to request the uploading of a VNF package by providing address information to the NFVO for retrieving the content of the VNF package. The POST method provides the information for the NFVO to get the content of a VNF package.\"\n","parameters":[{"name":"vnfPkgId","in":"path","required":true,"type":"string"},{"name":"UploadVnfPkgFromUriRequest","description":"\"The payload body contains the address information based on which the NFVO can obtain the content of the VNF package.\"\n","in":"body","required":true,"schema":{"type":"object","properties":{"userDefinedData":{"description":"This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions  defined in clause 4 of IETF RFC 7159.\n","type":"object"}},"description":"\"The payload body contains the address information based on which the NFVO can obtain the content of the VNF package\"\n"}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"}],"responses":{"202":{"description":"\"Accepted\"\n\"The information about the VNF package was received successfully, but the on-boarding has not been completed. It is expected to take some time for processing.\nThe response body shall be empty.\"\n"},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\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\nError: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to the fact that the onboarding state of the VNF package resource is not CREATED . 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 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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_packages/{vnfPkgId}/artifacts/{artifactPath}":{"parameters":[{"name":"artifactPath","description":"This resource represents an individual artifact contained in a VNF package.  The client can use this resource to fetch the content of the artifact.\n","in":"path","type":"string","required":true},{"name":"vnfPkgId","description":"Identifier of the on-boarded VNF package. The identifier is allocated by the NFVO. This identifier can be retrieved from the \"vnfPkgId\" attribute in the VnfPackageOnboardingNotification or VnfPackageChangeNotification.\n","in":"path","type":"string","required":true}],"get":{"summary":"IndividualVNF package artifact.","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response.\n","in":"header","required":true,"type":"string"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"},{"name":"Range","description":"The request may contain a \"Range\" HTTP header to obtain single range of bytes from the VNF package file. This can be used to continue an aborted transmission. If the NFVO does not support range requests, it should return the whole file with a 200 OK response instead.\n","in":"header","type":"string"}],"responses":{"200":{"description":"200 OK.\nOn success, the content of the artifact is returned. The payload body shall contain a copy of the artifact file from the VNF package, as defined by ETSI GS NFV-SOL 004. The \"Content-Type\" HTTP header shall be set according to the content type of the artifact file. If the content type cannot be determined, the header shall be set to the value \"application/octet-stream\".\n","headers":{"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}}},"206":{"description":"Partial Content.\nOn success, if the NFVO supports range requests, a single consecutive byte range from the content of the VNF package file is returned. The response body shall contain the requested part of the VNF package file. The \"Content-Range\" HTTP header shall be provided according to IETF RFC 7233. The \"Content-Type\" HTTP header shall be set as defined above for the \"200 OK\" response.\n","headers":{"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\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\nError: The operation cannot be executed currently, due to a conflict with the state of the resource. Typically, this is due to any of the following scenarios: - Disable a VNF package resource of hich the operational state is not ENABLED - Enable a VNF package resource of which the operational state is not DISABLED 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"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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":{"summary":"Subscriptions","description":"Subscribe.\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 VNFM, and might make sense only in very rare use cases. Consequently, the NFVO 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":"PkgmSubscriptionRequest","description":"Representation of the created subscription resource. The HTTP response shall include a \"Location\" HTTP header that points to the created subscription resource.\n","in":"body","required":true,"schema":{"description":"This type represents a subscription request related to VNF package management notifications about VNF package on boarding or changes.\n","type":"object","required":["callbackUri"],"properties":{"filter":{"description":"This type represents a subscription filter related to notifications related to VNF package management. 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":{"notificationTypes":{"description":"Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification\n","type":"string","enum":["VnfPackageOnboardingNotification","VnfPackageChangeNotification"]},"vnfProductsFromProviders":{"description":"If present, match VNF packages that contain VNF products from certain providers.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNFprovider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF packages that contain VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF packages that contain VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF packages that contain VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"}}}}}}}},"vnfdId":{"description":"Match VNF packages with a VNFD identifier listed in the attribute.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfPkgId":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"operationalState":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"type":"string","description":"\"The enumeration PackageOperationalStateType shall  comply with the provisions defined in Table 9.5.4.4-1.\" Acceptable values are: -ENABLED - The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances. -DISABLED - The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package is re-enabled).\n","enum":["ENABLED","DISABLED"]}},"usageState":{"description":"Match particular usage state of the on-boarded VNF package. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"type":"string","description":"\"The enumeration PackageUsageStateType shall comply with the provisions. Acceptable values are: -IN_USE - VNF instances instantiated from this VNF package exist. -NOT_IN_USE - No existing VNF instance is instantiated from this VNF package\"\n","enum":["IN_USE","NOT_IN_USE"]}}}}}}},"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  HTTP Basic authentication with the client credentials. \n* OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the  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  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"},"password":{"description":"Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.\n","type":"string"}}},"paramsOauth2ClientCredentials":{"description":"Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is \"OAUTH2_CLIENT_CREDENTIALS\" and the contained information has not been provisioned out of band. Shall be absent otherwise.\n","type":"object","properties":{"clientId":{"description":"Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type.  Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n","type":"string"},"clientPassword":{"description":"Client password to be used in the access token request of the OAuth 2.0 client credentials grant type.  Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.\n","type":"string"},"tokenEndpoint":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"}}}}}}}},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"},{"name":"Content-Type","description":"The MIME type of the body of the request. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"}],"responses":{"201":{"description":"Created Representation of the created subscription resource. The HTTP response shall include a \"Location\" HTTP header that points to the created subscription resource.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1},"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}},"schema":{"type":"array","items":{"description":"This type represents a subscription related to notifications about VNF package management.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications related to VNF package management. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n","type":"object","properties":{"notificationTypes":{"description":"Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification\n","type":"string","enum":["VnfPackageOnboardingNotification","VnfPackageChangeNotification"]},"vnfProductsFromProviders":{"description":"If present, match VNF packages that contain VNF products from certain providers.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNFprovider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF packages that contain VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF packages that contain VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF packages that contain VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"}}}}}}}},"vnfdId":{"description":"Match VNF packages with a VNFD identifier listed in the attribute.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfPkgId":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"operationalState":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"type":"string","description":"\"The enumeration PackageOperationalStateType shall  comply with the provisions defined in Table 9.5.4.4-1.\" Acceptable values are: -ENABLED - The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances. -DISABLED - The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package is re-enabled).\n","enum":["ENABLED","DISABLED"]}},"usageState":{"description":"Match particular usage state of the on-boarded VNF package. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"type":"string","description":"\"The enumeration PackageUsageStateType shall comply with the provisions. Acceptable values are: -IN_USE - VNF instances instantiated from this VNF package exist. -NOT_IN_USE - No existing VNF instance is instantiated from this VNF package\"\n","enum":["IN_USE","NOT_IN_USE"]}}}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource.\n","type":"object","required":["href"],"properties":{"href":{"description":"URI of the referenced resource.\n","type":"string","format":"url"}}}}}}}}},"303":{"description":"See Other A subscription with the same callbackURI and the same filter already exists and the policy of the VNFM is to not create redundant subscriptions. The HTTP response shall include a \"Location\" HTTP header that contains the resource URI of the existing subscription resource. The response body shall be empty.\n"},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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"}}}}}},"get":{"summary":"Query Subscription Information\n","description":"Query Subscription Information\nThe GET method queries the list of active subscriptions of the functional block that invokes the method. It can be used e.g. for resynchronization after error situations.\n","parameters":[{"name":"filter","in":"query","required":false,"type":"string","description":"\"Attribute-based filtering parameters according to clause 4.3.2. The NFVO shall support receiving filtering parameters as part of the URI query string. The OSS/BSS may supply filtering parameters. All attribute names that appear in the PkgmSubscription and in data types referenced from it shall be supported in attribute-based filtering parameters.\"\n"},{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"}],"responses":{"200":{"description":"OK Active subscriptions of the functional block that invokes the method.\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":{"type":"array","items":{"description":"This type represents a subscription related to notifications about VNF package management.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications related to VNF package management. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n","type":"object","properties":{"notificationTypes":{"description":"Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification\n","type":"string","enum":["VnfPackageOnboardingNotification","VnfPackageChangeNotification"]},"vnfProductsFromProviders":{"description":"If present, match VNF packages that contain VNF products from certain providers.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNFprovider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF packages that contain VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF packages that contain VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF packages that contain VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"}}}}}}}},"vnfdId":{"description":"Match VNF packages with a VNFD identifier listed in the attribute.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfPkgId":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"operationalState":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"type":"string","description":"\"The enumeration PackageOperationalStateType shall  comply with the provisions defined in Table 9.5.4.4-1.\" Acceptable values are: -ENABLED - The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances. -DISABLED - The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package is re-enabled).\n","enum":["ENABLED","DISABLED"]}},"usageState":{"description":"Match particular usage state of the on-boarded VNF package. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"type":"string","description":"\"The enumeration PackageUsageStateType shall comply with the provisions. Acceptable values are: -IN_USE - VNF instances instantiated from this VNF package exist. -NOT_IN_USE - No existing VNF instance is instantiated from this VNF package\"\n","enum":["IN_USE","NOT_IN_USE"]}}}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource.\n","type":"object","required":["href"],"properties":{"href":{"description":"URI of the referenced resource.\n","type":"string","format":"url"}}}}}}}}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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/{subscriptionId}":{"parameters":[{"name":"subscriptionId","description":"Identifier of this subscription. This identifier can be retrieved from the resource referenced by the \"Location\" HTTP header in the response to a POST request creating a new subscription resource. It can also be retrieved from the \"id\" attribute in the payload body of that response.\n","in":"path","type":"string","required":true}],"get":{"summary":"Query Subscription Information\n","description":"Query Subscription Information The GET method reads an individual subscription.\n","parameters":[{"name":"Accept","description":"Content-Types that are acceptable for the response. Reference: IETF RFC 7231\n","in":"header","required":true,"type":"string"},{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"}],"responses":{"200":{"description":"OK\nRepresentation of the subscription resource.\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":"This type represents a subscription related to notifications about VNF package management.\n","type":"object","required":["id","callbackUri","_links"],"properties":{"id":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"filter":{"description":"This type represents a subscription filter related to notifications related to VNF package management. At a particular nesting level in the filter structure, the following applies: All attributes shall match in order for the filter to match (logical \"and\" between different filter attributes). If an attribute is an array, the attribute shall match if at least one of the values in the array matches (logical \"or\" between the values of one filter attribute).\n","type":"object","properties":{"notificationTypes":{"description":"Match particular notification types. Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification\n","type":"string","enum":["VnfPackageOnboardingNotification","VnfPackageChangeNotification"]},"vnfProductsFromProviders":{"description":"If present, match VNF packages that contain VNF products from certain providers.\n","type":"array","items":{"type":"object","required":["vnfProvider"],"properties":{"vnfProvider":{"description":"Name of the VNFprovider to match.\n","type":"string"},"vnfProducts":{"description":"If present, match VNF packages that contain VNF products with certain product names, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfProductName"],"properties":{"vnfProductName":{"description":"Name of the VNF product to match.\n","type":"string"},"versions":{"description":"If present, match VNF packages that contain VNF products with certain versions and a certain product name, from one particular provider.\n","type":"array","items":{"type":"object","required":["vnfSoftwareVersion"],"properties":{"vnfSoftwareVersion":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"},"vnfdVersions":{"description":"If present, match VNF packages that contain VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.\n","type":"array","items":{"description":"Software version of the VNF. This is changed when there is any change to the software included in the VNF package. This information is copied from the VNFD. It shall be present after the VNF package content has been on-boarded and absent otherwise.\n","type":"string"}}}}}}}},"vnfdId":{"description":"Match VNF packages with a VNFD identifier listed in the attribute.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"vnfPkgId":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"description":"An identifier with the intention of being globally unique.\n","type":"string"}},"operationalState":{"description":"Match VNF packages with a package identifier listed in the attribute. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"type":"string","description":"\"The enumeration PackageOperationalStateType shall  comply with the provisions defined in Table 9.5.4.4-1.\" Acceptable values are: -ENABLED - The VNF package is enabled, i.e. it can be used for instantiation of new VNF instances. -DISABLED - The VNF package is disabled, i.e. it cannot be used for further VNF instantiation requests (unless and until the VNF package is re-enabled).\n","enum":["ENABLED","DISABLED"]}},"usageState":{"description":"Match particular usage state of the on-boarded VNF package. May be present if the \"notificationTypes\" attribute contains the value \"VnfPackageChangeNotification\", and shall be absent otherwise.\n","type":"array","items":{"type":"string","description":"\"The enumeration PackageUsageStateType shall comply with the provisions. Acceptable values are: -IN_USE - VNF instances instantiated from this VNF package exist. -NOT_IN_USE - No existing VNF instance is instantiated from this VNF package\"\n","enum":["IN_USE","NOT_IN_USE"]}}}}}}},"callbackUri":{"description":"String formatted according to IETF RFC 3986.\n","type":"string"},"_links":{"description":"Links to resources related to this resource.\n","type":"object","required":["self"],"properties":{"self":{"description":"This type represents a link to a resource.\n","type":"object","required":["href"],"properties":{"href":{"description":"URI of the referenced resource.\n","type":"string","format":"url"}}}}}}}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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"}}}}}},"delete":{"summary":"Terminate subscription\n","description":"Terminate subscription\nThe DELETE method terminates an individual subscription.\n","parameters":[{"name":"Authorization","description":"The authorization token for the request. Reference: IETF RFC 7235\n","in":"header","required":false,"type":"string"}],"responses":{"204":{"description":"No Content\nThe subscription resource was deleted successfully.\n","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.\n","type":"string","maximum":1,"minimum":0}}},"400":{"description":"Bad Request.\nError: Invalid attribute-based filtering parameters. 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"}}}},"401":{"description":"Unauthorized If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.\n","headers":{"Content-Type":{"type":"string","description":"The MIME type of the body of the response."},"WWW-Authenticate":{"type":"string","description":"Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.\n"}},"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 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.\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 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code.  The \"ProblemDetails\" structure may be provided, including in the \"detail\" attribute information about the source of the problem, e.g. a wrong resource URI variable.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"405":{"description":"Method Not Allowed If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The \"ProblemDetails\" structure may be omitted in that case.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"406":{"description":"If the \"Accept\" header does not contain at least one name of a content type for which the NFVO can provide a representation of the VNFD, the NFVO shall respond with this response code.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"416":{"description":"The byte range passed in the \"Range\" header did not match any available byte range in the NSD file (e.g. \"access after end of file\"). The response body may contain a ProblemDetails structure.\n","headers":{"Content-Type":{"description":"The MIME type of the body of the response.","type":"string","maximum":1,"minimum":1}},"schema":{"description":"The definition of the general \"ProblemDetails\" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the \"status\" and \"detail\" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the \"ProblemDetails\" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].\n","type":"object","required":["status","detail"],"properties":{"type":{"description":"A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be \"about:blank\".\n","type":"string","format":"URI"},"title":{"description":"A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than \"about:blank\", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).\n","type":"string"},"status":{"description":"The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.\n","type":"integer"},"detail":{"description":"A human-readable explanation specific to this occurrence of the problem.\n","type":"string"},"instance":{"description":"A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n","type":"string","format":"URI"}}}},"500":{"description":"Internal Server Error If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code (\"catch all error\"), the API producer shall respond withthis response code. The ProblemDetails structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\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 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the Retry-After HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\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"}}}}}}}}}