diff --git a/SOL002/README.md b/SOL002/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL002/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL002/VNFConfiguration-API_egm/README.md b/SOL002/VNFConfiguration-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL002/VNFConfiguration-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL002/VNFFaultManagement-API_egm/README.md b/SOL002/VNFFaultManagement-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL002/VNFFaultManagement-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL002/VNFIndicator-API_nxw/README.md b/SOL002/VNFIndicator-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL002/VNFIndicator-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL002/VNFIndicatorNotification-API_nxw/README.md b/SOL002/VNFIndicatorNotification-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL002/VNFIndicatorNotification-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL002/VNFLifecycleManagement-API_egm/README.md b/SOL002/VNFLifecycleManagement-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL002/VNFLifecycleManagement-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL002/VNFPerformanceManagement-API_nxw/README.md b/SOL002/VNFPerformanceManagement-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL002/VNFPerformanceManagement-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL002/gs_NFV-SOL002v020401p.pdf b/SOL002/gs_NFV-SOL002v020401p.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..5cdf56a81964dad1c293b7902f85e3c7156f20a4
Binary files /dev/null and b/SOL002/gs_NFV-SOL002v020401p.pdf differ
diff --git a/SOL003/README.md b/SOL003/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFFaultManagement-API_egm/README.md b/SOL003/VNFFaultManagement-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFFaultManagement-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFFaultManagementNotification-API_egm/README.md b/SOL003/VNFFaultManagementNotification-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFFaultManagementNotification-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFIndicator-API_nxw/README.md b/SOL003/VNFIndicator-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFIndicator-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFIndicatorNotification-API_nxw/README.md b/SOL003/VNFIndicatorNotification-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFIndicatorNotification-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFLifecycleManagement-API_egm/README.md b/SOL003/VNFLifecycleManagement-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFLifecycleManagement-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFLifecycleOperationGranting-API_egm/README.md b/SOL003/VNFLifecycleOperationGranting-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFLifecycleOperationGranting-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFPackageManagement-API_nxw/README.md b/SOL003/VNFPackageManagement-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFPackageManagement-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFPackageManagement-API_nxw/VNFPackageManagement.yaml b/SOL003/VNFPackageManagement-API_nxw/VNFPackageManagement.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..3c44c93fc35c7dfd9557a613a59b34608411299f
--- /dev/null
+++ b/SOL003/VNFPackageManagement-API_nxw/VNFPackageManagement.yaml
@@ -0,0 +1,8387 @@
+swagger: '2.0'
+info:
+ version: 1.1.1
+ title: SOL003 - VNF Package Management interface
+ description: >
+ SOL003 - VNF Package Management interface
+
+
+ IMPORTANT: Please note that this file might be not aligned to the current
+ version of the ETSI Group Specification it refers to. In case of
+ discrepancies the published ETSI Group Specification takes precedence.
+
+
+ In clause 4.3.2 of ETSI GS NFV-SOL 003 v2.4.1, an attribute-based filtering
+ mechanism is defined. This mechanism is currently not included in the
+ corresponding OpenAPI design for this GS version. Changes to the
+ attribute-based filtering mechanism are being considered in v2.5.1 of this
+ GS for inclusion in the corresponding future ETSI NFV OpenAPI design.
+
+ Please report bugs to
+ https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=
+ license:
+ name: ETSI Forge copyright notice
+ url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt'
+externalDocs:
+ description: ETSI GS NFV-SOL 003 V2.4.1
+ url: >-
+ http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.04.01_60/gs_NFV-SOL003v020401p.pdf
+basePath: /vnfpkgm/v1
+schemes:
+ - https
+consumes:
+ - application/json
+produces:
+ - application/json
+paths:
+ /vnf_packages:
+ get:
+ description: >
+ Query VNF Package Info
+
+
+ The GET method queries the information of the VNF packages matching the
+ filter.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '200':
+ description: |
+ OK
+ Information of the selected VNF packages.
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ type: array
+ items:
+ description: |
+ This type represents the information of an VNF package.
+ type: object
+ required:
+ - id
+ - operationalState
+ - usageState
+ - _links
+ properties:
+ id:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ vnfdId:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ vnfProvider:
+ description: >
+ Provider of the VNF package and the VNFD. This information
+ is copied from the VNFD.
+ 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.
+ type: string
+ vnfSoftwareVersion:
+ description: |
+ A Version.
+ type: string
+ vnfdVersion:
+ description: |
+ A Version.
+ type: string
+ checksum:
+ description: >
+ This type represents the checksum of a VNF package or an
+ artifact file.
+ type: object
+ required:
+ - algorithm
+ - hash
+ properties:
+ algorithm:
+ description: >
+ Name of the algorithm used to generate the checksum, as
+ defined in ETSI GS NFV-SOL 004. For example, SHA-256,
+ SHA-512.
+ type: string
+ hash:
+ description: |
+ The hexadecimal value of the checksum.
+ type: string
+ softwareImages:
+ description: >
+ Information about VNF package artifacts that are software
+ images. This attribute shall not be present before the VNF
+ package content is on-boarded. Otherwise, this attribute
+ shall be present unless it has been requested to be excluded
+ per attribute selector.
+ type: array
+ items:
+ description: >
+ This type represents an artifact contained in a VNF
+ package which represents a software image.
+ type: object
+ required:
+ - id
+ - name
+ - provider
+ - version
+ - checksum
+ - containerFormat
+ - diskFormat
+ - createdAt
+ - minDisk
+ - minRam
+ - size
+ - imagePath
+ properties:
+ id:
+ description: |
+ An identifier that is unique within a VNF descriptor.
+ type: string
+ name:
+ description: |
+ Name of the software image.
+ type: string
+ provider:
+ description: |
+ Provider of the software image.
+ type: string
+ version:
+ description: |
+ A Version.
+ type: string
+ checksum:
+ description: >
+ This type represents the checksum of a VNF package or
+ an artifact file.
+ type: object
+ required:
+ - algorithm
+ - hash
+ properties:
+ algorithm:
+ description: >
+ Name of the algorithm used to generate the
+ checksum, as defined in ETSI GS NFV-SOL 004. For
+ example, SHA-256, SHA-512.
+ type: string
+ hash:
+ description: |
+ The hexadecimal value of the checksum.
+ 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 The list of permitted values
+ was taken from "Container formats" in
+ http://docs.openstack.org/image-guide/image-formats.html
+ 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 The list of permitted
+ values was adapted from "Disk formats" in
+ http://docs.openstack.org/image-guide/image-formats.html
+ type: string
+ enum:
+ - AKI
+ - AMI
+ - ISO
+ - QCOW2
+ - RAW
+ - VDI
+ - VHD
+ - VHDX
+ - VMDK
+ createdAt:
+ description: >
+ Date-time stamp. Representation: String formatted
+ according to IETF RFC 3339.
+ type: string
+ format: date-time
+ minDisk:
+ description: |
+ The minimal disk for this software image in bytes.
+ type: integer
+ minRam:
+ description: |
+ The minimal RAM for this software image in bytes.
+ type: integer
+ size:
+ description: |
+ Size of this software image in bytes.
+ type: integer
+ userMetadata:
+ description: >
+ This type represents a list of key-value pairs. The
+ order of the pairs in the list is not significant. In
+ JSON, a set of key- value pairs is represented as an
+ object. It shall comply with the provisions defined
+ in clause 4 of IETF RFC 7159.
+ 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.
+ type: string
+ additionalArtifacts:
+ description: >
+ Information about VNF package artifacts contained in the VNF
+ package that are not software images. This attribute shall
+ not be present before the VNF package content is on-boarded.
+ Otherwise, this attribute shall be present if the VNF
+ package contains additional artifacts.
+ type: array
+ items:
+ description: >
+ This type represents an artifact other than a software
+ image which is contained in a VNF package.
+ type: object
+ required:
+ - artifactPath
+ - checksum
+ properties:
+ artifactPath:
+ description: >
+ Path in the VNF package, which identifies the artifact
+ and also allows to access a copy of the artifact.
+ type: string
+ checksum:
+ description: >
+ This type represents the checksum of a VNF package or
+ an artifact file.
+ type: object
+ required:
+ - algorithm
+ - hash
+ properties:
+ algorithm:
+ description: >
+ Name of the algorithm used to generate the
+ checksum, as defined in ETSI GS NFV-SOL 004. For
+ example, SHA-256, SHA-512.
+ type: string
+ hash:
+ description: |
+ The hexadecimal value of the checksum.
+ type: string
+ metadata:
+ description: >
+ This type represents a list of key-value pairs. The
+ order of the pairs in the list is not significant. In
+ JSON, a set of key- value pairs is represented as an
+ object. It shall comply with the provisions defined
+ in clause 4 of IETF RFC 7159.
+ type: object
+ onboardingState:
+ description: >
+ CREATED: The VNF package resource has been created.
+ UPLOADING: The associated VNF package content is being
+ uploaded. PROCESSING: The associated VNF package content is
+ being processed, e.g.,
+ validation.
+ ONBOARDED: The associated VNF package content has been
+ successfully
+ on-boarded.
+ type: string
+ enum:
+ - CREATED
+ - UPLOADING
+ - PROCESSING
+ - ONBOARDED
+ operationalState:
+ description: >
+ - 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).
+ type: string
+ enum:
+ - ENABLED
+ - DISABLED
+ usageState:
+ description: >
+ - IN_USE: VNF instances instantiated from this VNF package
+ exist. - NOT_IN_USE: No existing VNF instance is
+ instantiated from this VNF
+ package.
+ 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.
+ type: object
+ _links:
+ description: |
+ Links to resources related to this resource.
+ type: object
+ required:
+ - self
+ - packageContent
+ properties:
+ self:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ vnfd:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ packageContent:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ '400':
+ description: >
+ Bad Request
+
+ It fhe request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem. If the request contains a malformed access
+ token, the API producer should respond with this response. The
+ details of the error shall be returned in the WWW-Authenticate HTTP
+ header, as defined in IETF RFC 6750 and IETF RFC 7235. The
+ ProblemDetails structure may be provided. If there is an application
+ error related to the client's input that cannot be easily mapped to
+ any other HTTP response code ("catch all error"), the API producer
+ shall respond with this response code.The "ProblemDetails" structure
+ shall be provided, and shall include in the "detail" attribute more
+ information about the source of the problem.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ This code is returned if the requested byte range in the Range HTTP
+ header is not present in the requested resource.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '/vnf_packages/{vnfPkgId}':
+ parameters:
+ - name: vnfPkgId
+ description: >
+ Identifier of the VNF package. The identifier is allocated by the
+ NFVO. This identifier can be retrieved from the "vnfPkgId" attribute
+ in the VnfPackageOnboardingNotification or
+ VnfPackageChangeNotification.
+ in: path
+ type: string
+ required: true
+ get:
+ description: |
+ Query VNF Package Info
+
+ The GET method reads the information of an individual VNF package.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '200':
+ description: |
+ OK
+ Information of the selected VNF packages.
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: |
+ This type represents the information of an VNF package.
+ type: object
+ required:
+ - id
+ - operationalState
+ - usageState
+ - _links
+ properties:
+ id:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ vnfdId:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ vnfProvider:
+ description: >
+ Provider of the VNF package and the VNFD. This information is
+ copied from the VNFD.
+ 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.
+ type: string
+ vnfSoftwareVersion:
+ description: |
+ A Version.
+ type: string
+ vnfdVersion:
+ description: |
+ A Version.
+ type: string
+ checksum:
+ description: >
+ This type represents the checksum of a VNF package or an
+ artifact file.
+ type: object
+ required:
+ - algorithm
+ - hash
+ properties:
+ algorithm:
+ description: >
+ Name of the algorithm used to generate the checksum, as
+ defined in ETSI GS NFV-SOL 004. For example, SHA-256,
+ SHA-512.
+ type: string
+ hash:
+ description: |
+ The hexadecimal value of the checksum.
+ type: string
+ softwareImages:
+ description: >
+ Information about VNF package artifacts that are software
+ images. This attribute shall not be present before the VNF
+ package content is on-boarded. Otherwise, this attribute shall
+ be present unless it has been requested to be excluded per
+ attribute selector.
+ type: array
+ items:
+ description: >
+ This type represents an artifact contained in a VNF package
+ which represents a software image.
+ type: object
+ required:
+ - id
+ - name
+ - provider
+ - version
+ - checksum
+ - containerFormat
+ - diskFormat
+ - createdAt
+ - minDisk
+ - minRam
+ - size
+ - imagePath
+ properties:
+ id:
+ description: |
+ An identifier that is unique within a VNF descriptor.
+ type: string
+ name:
+ description: |
+ Name of the software image.
+ type: string
+ provider:
+ description: |
+ Provider of the software image.
+ type: string
+ version:
+ description: |
+ A Version.
+ type: string
+ checksum:
+ description: >
+ This type represents the checksum of a VNF package or an
+ artifact file.
+ type: object
+ required:
+ - algorithm
+ - hash
+ properties:
+ algorithm:
+ description: >
+ Name of the algorithm used to generate the checksum,
+ as defined in ETSI GS NFV-SOL 004. For example,
+ SHA-256, SHA-512.
+ type: string
+ hash:
+ description: |
+ The hexadecimal value of the checksum.
+ 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 The list of permitted values was taken from
+ "Container formats" in
+ http://docs.openstack.org/image-guide/image-formats.html
+ 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 The list of permitted values was
+ adapted from "Disk formats" in
+ http://docs.openstack.org/image-guide/image-formats.html
+ type: string
+ enum:
+ - AKI
+ - AMI
+ - ISO
+ - QCOW2
+ - RAW
+ - VDI
+ - VHD
+ - VHDX
+ - VMDK
+ createdAt:
+ description: >
+ Date-time stamp. Representation: String formatted
+ according to IETF RFC 3339.
+ type: string
+ format: date-time
+ minDisk:
+ description: |
+ The minimal disk for this software image in bytes.
+ type: integer
+ minRam:
+ description: |
+ The minimal RAM for this software image in bytes.
+ type: integer
+ size:
+ description: |
+ Size of this software image in bytes.
+ type: integer
+ userMetadata:
+ description: >
+ This type represents a list of key-value pairs. The
+ order of the pairs in the list is not significant. In
+ JSON, a set of key- value pairs is represented as an
+ object. It shall comply with the provisions defined in
+ clause 4 of IETF RFC 7159.
+ 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.
+ type: string
+ additionalArtifacts:
+ description: >
+ Information about VNF package artifacts contained in the VNF
+ package that are not software images. This attribute shall not
+ be present before the VNF package content is on-boarded.
+ Otherwise, this attribute shall be present if the VNF package
+ contains additional artifacts.
+ type: array
+ items:
+ description: >
+ This type represents an artifact other than a software image
+ which is contained in a VNF package.
+ type: object
+ required:
+ - artifactPath
+ - checksum
+ properties:
+ artifactPath:
+ description: >
+ Path in the VNF package, which identifies the artifact
+ and also allows to access a copy of the artifact.
+ type: string
+ checksum:
+ description: >
+ This type represents the checksum of a VNF package or an
+ artifact file.
+ type: object
+ required:
+ - algorithm
+ - hash
+ properties:
+ algorithm:
+ description: >
+ Name of the algorithm used to generate the checksum,
+ as defined in ETSI GS NFV-SOL 004. For example,
+ SHA-256, SHA-512.
+ type: string
+ hash:
+ description: |
+ The hexadecimal value of the checksum.
+ type: string
+ metadata:
+ description: >
+ This type represents a list of key-value pairs. The
+ order of the pairs in the list is not significant. In
+ JSON, a set of key- value pairs is represented as an
+ object. It shall comply with the provisions defined in
+ clause 4 of IETF RFC 7159.
+ type: object
+ onboardingState:
+ description: >
+ CREATED: The VNF package resource has been created. UPLOADING:
+ The associated VNF package content is being uploaded.
+ PROCESSING: The associated VNF package content is being
+ processed, e.g.,
+ validation.
+ ONBOARDED: The associated VNF package content has been
+ successfully
+ on-boarded.
+ type: string
+ enum:
+ - CREATED
+ - UPLOADING
+ - PROCESSING
+ - ONBOARDED
+ operationalState:
+ description: >
+ - 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).
+ type: string
+ enum:
+ - ENABLED
+ - DISABLED
+ usageState:
+ description: >
+ - IN_USE: VNF instances instantiated from this VNF package
+ exist. - NOT_IN_USE: No existing VNF instance is instantiated
+ from this VNF
+ package.
+ 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.
+ type: object
+ _links:
+ description: |
+ Links to resources related to this resource.
+ type: object
+ required:
+ - self
+ - packageContent
+ properties:
+ self:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ vnfd:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ packageContent:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem. If the request contains a malformed access
+ token, the API producer should respond with this response. The
+ details of the error shall be returned in the WWW-Authenticate HTTP
+ header, as defined in IETF RFC 6750 and IETF RFC 7235. The
+ ProblemDetails structure may be provided. If there is an application
+ error related to the client's input that cannot be easily mapped to
+ any other HTTP response code ("catch all error"), the API producer
+ shall respond with this response code.The "ProblemDetails" structure
+ shall be provided, and shall include in the "detail" attribute more
+ information about the source of the problem.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ This code is returned if the requested byte range in the Range HTTP
+ header is not present in the requested resource.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '/vnf_packages/{vnfPkgId}/vnfd':
+ parameters:
+ - 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.
+ in: path
+ type: string
+ required: true
+ get:
+ description: >
+ Query VNF Package Info
+
+
+ The GET method reads the content of the VNFD within a VNF package. 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 where only the YAML files representing the VNFD, and
+ information needed 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.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Permitted
+ values: "text/plain" and/or "application/zip" Reference: IETF RFC
+ 7231
+ in: header
+ required: true
+ type: string
+ enum:
+ - text/plain
+ - application/zip
+ - text/plain+application/zip
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '200':
+ description: >
+ OK
+
+ On 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.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ enum:
+ - text/plain
+ - application/zip
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem. If the request contains a malformed access
+ token, the API producer should respond with this response. The
+ details of the error shall be returned in the WWW-Authenticate HTTP
+ header, as defined in IETF RFC 6750 and IETF RFC 7235. The
+ ProblemDetails structure may be provided. If there is an application
+ error related to the client's input that cannot be easily mapped to
+ any other HTTP response code ("catch all error"), the API producer
+ shall respond with this response code.The "ProblemDetails" structure
+ shall be provided, and shall include in the "detail" attribute more
+ information about the source of the problem.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ 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. The
+ "ProblemDetails" structure may be included with the "detail"
+ attribute providing more information about the error.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '409':
+ description: >
+ Conflict
+
+ Error: The operation cannot be executed currently, due to a conflict
+ with the state of the resource. Typically, this is due to the fact
+ that "onboardingState" of the VNF package has a value different from
+ "ONBOARDED". The response body shall contain a ProblemDetails
+ structure, in which the "detail" attribute shall convey more
+ information about the error.
+ headers:
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ This code is returned if the requested byte range in the Range HTTP
+ header is not present in the requested resource.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '/vnf_packages/{vnfPkgId}/package_content':
+ parameters:
+ - 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.
+ in: path
+ type: string
+ required: true
+ get:
+ description: >
+ Fetch VNF Package
+
+
+ The GET method fetches the content of a VNF package identified by the
+ VNF package identifier allocated by the NFVO.
+ parameters:
+ - name: Accept
+ description: |
+ Content-Types that are acceptable for the response.
+ in: header
+ required: true
+ type: string
+ enum:
+ - text/plain
+ - application/zip
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ 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.
+ in: header
+ type: string
+ responses:
+ '200':
+ description: >
+ OK
+
+ On 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.
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ '206':
+ description: >
+ Partial Content
+
+ On 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.
+ headers:
+ Content-Range:
+ type: string
+ maximum: 1
+ minimum: 1
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem. If the request contains a malformed access
+ token, the API producer should respond with this response. The
+ details of the error shall be returned in the WWW-Authenticate HTTP
+ header, as defined in IETF RFC 6750 and IETF RFC 7235. The
+ ProblemDetails structure may be provided. If there is an application
+ error related to the client's input that cannot be easily mapped to
+ any other HTTP response code ("catch all error"), the API producer
+ shall respond with this response code.The "ProblemDetails" structure
+ shall be provided, and shall include in the "detail" attribute more
+ information about the source of the problem.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '409':
+ description: >
+ Conflict
+
+ Error: The operation cannot be executed currently, due to a conflict
+ with the state of the resource. Typically, this is due to the fact
+ that "onboardingState" of the VNF package has a value different from
+ "ONBOARDED". The response body shall contain a ProblemDetails
+ structure, in which the "detail" attribute shall convey more
+ information about the error.
+ headers:
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ The byte range passed in the "Range" header did not match any
+ available byte range in the VNF package file (e.g. "access after end
+ of file"). The response body may contain a ProblemDetails structure.
+ headers:
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '/vnf_packages/{vnfPkgId}/artifacts/{artifactPath}':
+ parameters:
+ - name: artifactPath
+ description: >
+ Path of the artifact within the VNF package. This identifier can be
+ retrieved from the "artifactPath" attribute of the applicable
+ "additionalArtifacts" entry in the body of the response to a GET
+ request querying the "Individual VNF package" or the "VNF packages"
+ resource.
+ 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.
+ in: path
+ type: string
+ required: true
+ get:
+ description: |
+ Fetch VNF Package Artifacts
+
+ The GET method fetches the content of an artifact within a VNF package.
+ parameters:
+ - name: Accept
+ description: |
+ Content-Types that are acceptable for the response.
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ 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.
+ in: header
+ type: string
+ responses:
+ '200':
+ description: >
+ OK
+
+ On 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".
+ headers:
+ Content-Type:
+ description: >
+ The MIME type of the body of the response. The "Content-Type"
+ HTTP header shall be set according to the content type of the
+ artifact file. If the content type cannot be determined, the
+ header shall be set to the value "application/octet-stream".
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ '206':
+ description: >
+ Partial Content
+
+ On 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.
+ headers:
+ Content-Range:
+ type: string
+ maximum: 1
+ minimum: 1
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem. If the request contains a malformed access
+ token, the API producer should respond with this response. The
+ details of the error shall be returned in the WWW-Authenticate HTTP
+ header, as defined in IETF RFC 6750 and IETF RFC 7235. The
+ ProblemDetails structure may be provided. If there is an application
+ error related to the client's input that cannot be easily mapped to
+ any other HTTP response code ("catch all error"), the API producer
+ shall respond with this response code.The "ProblemDetails" structure
+ shall be provided, and shall include in the "detail" attribute more
+ information about the source of the problem.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '409':
+ description: >
+ Conflict
+
+ Error: The operation cannot be executed currently, due to a conflict
+ with the state of the resource. Typically, this is due to the fact
+ that "onboardingState" of the VNF package has a value different from
+ "ONBOARDED". The response body shall contain a ProblemDetails
+ structure, in which the "detail" attribute shall convey more
+ information about the error.
+ headers:
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ The byte range passed in the "Range" header did not match any
+ available byte range in the VNF package file (e.g. "access after end
+ of file"). The response body may contain a ProblemDetails structure.
+ headers:
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ /subscriptions:
+ post:
+ description: >
+ Subscribe
+
+
+ The 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).
+ 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.
+ 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.
+ 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).
+ type: object
+ properties:
+ notificationTypes:
+ description: >
+ Match particular notification types. Permitted values: -
+ VnfPackageOnboardingNotification -
+ VnfPackageChangeNotification The permitted values of the
+ "notificationTypes" attribute are spelled exactly as the
+ names of the notification types to facilitate automated
+ code generation systems.
+ type: array
+ items:
+ type: string
+ enum:
+ - VnfPackageOnboardingNotification
+ - VnfPackageChangeNotification
+ vnfProductsFromProviders:
+ description: >
+ If present, match VNF packages that contain VNF products
+ from certain providers. The attributes
+ "vnfProductsFromProviders", "vnfdId" and "vnfPkgId" are
+ alternatives to reference to particular VNF packages in a
+ filter. They should not be used both in the same filter
+ instance, but one alternative should be chosen.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProvider
+ properties:
+ vnfProvider:
+ description: |
+ Name of the VNF provider to match.
+ type: string
+ vnfProducts:
+ description: >
+ If present, match VNF packages that contain VNF
+ products with certain product names, from one
+ particular provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProductName
+ properties:
+ vnfProductName:
+ description: |
+ Name of the VNF product to match.
+ type: string
+ versions:
+ description: >
+ If present, match VNF packages that contain
+ VNF products with certain versions and a
+ certain product name, from one particular
+ provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfSoftwareVersion
+ properties:
+ vnfSoftwareVersion:
+ description: |
+ A Version.
+ type: string
+ vnfdVersions:
+ description: >
+ If present, match VNF packages that
+ contain VNF products with certain VNFD
+ versions, a certain software version and
+ a certain product name, from one
+ particular provider.
+ type: array
+ items:
+ description: |
+ A Version.
+ type: string
+ vnfdId:
+ description: >
+ Match VNF packages with a VNFD identifier listed in the
+ attribute. The attributes "vnfProductsFromProviders",
+ "vnfdId" and "vnfPkgId" are alternatives to reference to
+ particular VNF packages in a filter. They should not be
+ used both in the same filter instance, but one alternative
+ should be chosen.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ vnfPkgId:
+ description: >
+ Match VNF packages with a package identifier listed in the
+ attribute. May be present if the "notificationTypes"
+ attribute contains the value
+ "VnfPackageChangeNotification", and shall be absent
+ otherwise. The attributes "vnfProductsFromProviders",
+ "vnfdId" and "vnfPkgId" are alternatives to reference to
+ particular VNF packages in a filter. They should not be
+ used both in the same filter instance, but one alternative
+ should be chosen.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ operationalState:
+ description: >
+ - ENABLED: The VNF package is enabled, i.e. it can be used
+ for
+ 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).
+ type: string
+ enum:
+ - ENABLED
+ - DISABLED
+ usageState:
+ description: >
+ - IN_USE: VNF instances instantiated from this VNF package
+ exist. - NOT_IN_USE: No existing VNF instance is
+ instantiated from this VNF
+ package.
+ callbackUri:
+ description: |
+ String formatted according to IETF RFC 3986.
+ 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.
+ * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the
+ notification endpoint, use an OAuth 2.0 Bearer token, obtained
+ using the client credentials grant type.
+ * TLS_CERT: Every HTTP request to the notification
+ endpoint is sent
+ over a mutually authenticated TLS session, i.e. not only the
+ server is authenticated, but also the client is authenticated
+ during the TLS tunnel setup.
+ type: array
+ items:
+ type: string
+ enum:
+ - BASIC
+ - OAUTH2_CLIENT_CREDENTIALS
+ - TLS_CERT
+ paramsBasic:
+ description: >
+ Parameters for authentication/authorization using BASIC.
+ Shall be present if authType is "BASIC" and the contained
+ information has not been provisioned out of band. Shall be
+ absent otherwise.
+ type: object
+ properties:
+ userName:
+ description: >
+ Username to be used in HTTP Basic authentication.
+ Shall be present if it has not been provisioned out of
+ band.
+ type: string
+ password:
+ description: >
+ Password to be used in HTTP Basic authentication.
+ Shall be present if it has not been provisioned out of
+ band.
+ type: string
+ paramsOauth2ClientCredentials:
+ description: >
+ Parameters for authentication/authorization using
+ OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is
+ "OAUTH2_CLIENT_CREDENTIALS" and the contained information
+ has not been provisioned out of band. Shall be absent
+ otherwise.
+ type: object
+ properties:
+ clientId:
+ description: >
+ Client identifier to be used in the access token
+ request of the OAuth 2.0 client credentials grant
+ type. Shall be present if it has not been provisioned
+ out of band. The clientId and clientPassword passed in
+ a subscription shall not be the same as the clientId
+ and clientPassword that are used to obtain
+ authorization for API requests. Client credentials may
+ differ between subscriptions. The value of
+ clientPassword should be generated by a random
+ process.
+ type: 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.
+ type: string
+ tokenEndpoint:
+ description: |
+ String formatted according to IETF RFC 3986.
+ type: string
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ - name: Content-Type
+ description: |
+ The MIME type of the body of the request. Reference: IETF RFC 7231
+ 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.
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ type: array
+ items:
+ description: >
+ This type represents a subscription related to notifications
+ about VNF package management.
+ type: object
+ required:
+ - id
+ - callbackUri
+ - _links
+ properties:
+ id:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ filter:
+ description: >
+ This type represents a subscription filter related to
+ notifications related to VNF package management. At a
+ particular nesting level in the filter structure, the
+ following applies: All attributes shall match in order for
+ the filter to match (logical "and" between different filter
+ attributes). If an attribute is an array, the attribute
+ shall match if at least one of the values in the array
+ matches (logical "or" between the values of one filter
+ attribute).
+ type: object
+ properties:
+ notificationTypes:
+ description: >
+ Match particular notification types. Permitted values: -
+ VnfPackageOnboardingNotification -
+ VnfPackageChangeNotification The permitted values of the
+ "notificationTypes" attribute are spelled exactly as the
+ names of the notification types to facilitate automated
+ code generation systems.
+ type: array
+ items:
+ type: string
+ enum:
+ - VnfPackageOnboardingNotification
+ - VnfPackageChangeNotification
+ vnfProductsFromProviders:
+ description: >
+ If present, match VNF packages that contain VNF products
+ from certain providers. The attributes
+ "vnfProductsFromProviders", "vnfdId" and "vnfPkgId" are
+ alternatives to reference to particular VNF packages in
+ a filter. They should not be used both in the same
+ filter instance, but one alternative should be chosen.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProvider
+ properties:
+ vnfProvider:
+ description: |
+ Name of the VNF provider to match.
+ type: string
+ vnfProducts:
+ description: >
+ If present, match VNF packages that contain VNF
+ products with certain product names, from one
+ particular provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProductName
+ properties:
+ vnfProductName:
+ description: |
+ Name of the VNF product to match.
+ type: string
+ versions:
+ description: >
+ If present, match VNF packages that contain
+ VNF products with certain versions and a
+ certain product name, from one particular
+ provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfSoftwareVersion
+ properties:
+ vnfSoftwareVersion:
+ description: |
+ A Version.
+ type: string
+ vnfdVersions:
+ description: >
+ If present, match VNF packages that
+ contain VNF products with certain VNFD
+ versions, a certain software version and
+ a certain product name, from one
+ particular provider.
+ type: array
+ items:
+ description: |
+ A Version.
+ type: string
+ vnfdId:
+ description: >
+ Match VNF packages with a VNFD identifier listed in the
+ attribute. The attributes "vnfProductsFromProviders",
+ "vnfdId" and "vnfPkgId" are alternatives to reference to
+ particular VNF packages in a filter. They should not be
+ used both in the same filter instance, but one
+ alternative should be chosen.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ vnfPkgId:
+ description: >
+ Match VNF packages with a package identifier listed in
+ the attribute. May be present if the "notificationTypes"
+ attribute contains the value
+ "VnfPackageChangeNotification", and shall be absent
+ otherwise. The attributes "vnfProductsFromProviders",
+ "vnfdId" and "vnfPkgId" are alternatives to reference to
+ particular VNF packages in a filter. They should not be
+ used both in the same filter instance, but one
+ alternative should be chosen.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ operationalState:
+ description: >
+ - ENABLED: The VNF package is enabled, i.e. it can be
+ used for
+ 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).
+ type: string
+ enum:
+ - ENABLED
+ - DISABLED
+ usageState:
+ description: >
+ - IN_USE: VNF instances instantiated from this VNF
+ package exist. - NOT_IN_USE: No existing VNF instance is
+ instantiated from this VNF
+ package.
+ callbackUri:
+ description: |
+ String formatted according to IETF RFC 3986.
+ type: string
+ _links:
+ description: |
+ Links to resources related to this resource.
+ type: object
+ required:
+ - self
+ properties:
+ self:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ 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.
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem. If the request contains a malformed access
+ token, the API producer should respond with this response. The
+ details of the error shall be returned in the WWW-Authenticate HTTP
+ header, as defined in IETF RFC 6750 and IETF RFC 7235. The
+ ProblemDetails structure may be provided. If there is an application
+ error related to the client's input that cannot be easily mapped to
+ any other HTTP response code ("catch all error"), the API producer
+ shall respond with this response code.The "ProblemDetails" structure
+ shall be provided, and shall include in the "detail" attribute more
+ information about the source of the problem.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ This code is returned if the requested byte range in the Range HTTP
+ header is not present in the requested resource.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ get:
+ description: >
+ Query Subscription Information
+
+
+ The GET method queries the list of active subscriptions of the
+ functional block that invokes the method. It can be used e.g. for
+ resynchronization after error situations.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '200':
+ description: >
+ OK
+
+ Active subscriptions of the functional block that invokes the
+ method.
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ type: array
+ items:
+ description: >
+ This type represents a subscription related to notifications
+ about VNF package management.
+ type: object
+ required:
+ - id
+ - callbackUri
+ - _links
+ properties:
+ id:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ filter:
+ description: >
+ This type represents a subscription filter related to
+ notifications related to VNF package management. At a
+ particular nesting level in the filter structure, the
+ following applies: All attributes shall match in order for
+ the filter to match (logical "and" between different filter
+ attributes). If an attribute is an array, the attribute
+ shall match if at least one of the values in the array
+ matches (logical "or" between the values of one filter
+ attribute).
+ type: object
+ properties:
+ notificationTypes:
+ description: >
+ Match particular notification types. Permitted values: -
+ VnfPackageOnboardingNotification -
+ VnfPackageChangeNotification The permitted values of the
+ "notificationTypes" attribute are spelled exactly as the
+ names of the notification types to facilitate automated
+ code generation systems.
+ type: array
+ items:
+ type: string
+ enum:
+ - VnfPackageOnboardingNotification
+ - VnfPackageChangeNotification
+ vnfProductsFromProviders:
+ description: >
+ If present, match VNF packages that contain VNF products
+ from certain providers. The attributes
+ "vnfProductsFromProviders", "vnfdId" and "vnfPkgId" are
+ alternatives to reference to particular VNF packages in
+ a filter. They should not be used both in the same
+ filter instance, but one alternative should be chosen.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProvider
+ properties:
+ vnfProvider:
+ description: |
+ Name of the VNF provider to match.
+ type: string
+ vnfProducts:
+ description: >
+ If present, match VNF packages that contain VNF
+ products with certain product names, from one
+ particular provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProductName
+ properties:
+ vnfProductName:
+ description: |
+ Name of the VNF product to match.
+ type: string
+ versions:
+ description: >
+ If present, match VNF packages that contain
+ VNF products with certain versions and a
+ certain product name, from one particular
+ provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfSoftwareVersion
+ properties:
+ vnfSoftwareVersion:
+ description: |
+ A Version.
+ type: string
+ vnfdVersions:
+ description: >
+ If present, match VNF packages that
+ contain VNF products with certain VNFD
+ versions, a certain software version and
+ a certain product name, from one
+ particular provider.
+ type: array
+ items:
+ description: |
+ A Version.
+ type: string
+ vnfdId:
+ description: >
+ Match VNF packages with a VNFD identifier listed in the
+ attribute. The attributes "vnfProductsFromProviders",
+ "vnfdId" and "vnfPkgId" are alternatives to reference to
+ particular VNF packages in a filter. They should not be
+ used both in the same filter instance, but one
+ alternative should be chosen.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ vnfPkgId:
+ description: >
+ Match VNF packages with a package identifier listed in
+ the attribute. May be present if the "notificationTypes"
+ attribute contains the value
+ "VnfPackageChangeNotification", and shall be absent
+ otherwise. The attributes "vnfProductsFromProviders",
+ "vnfdId" and "vnfPkgId" are alternatives to reference to
+ particular VNF packages in a filter. They should not be
+ used both in the same filter instance, but one
+ alternative should be chosen.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ operationalState:
+ description: >
+ - ENABLED: The VNF package is enabled, i.e. it can be
+ used for
+ 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).
+ type: string
+ enum:
+ - ENABLED
+ - DISABLED
+ usageState:
+ description: >
+ - IN_USE: VNF instances instantiated from this VNF
+ package exist. - NOT_IN_USE: No existing VNF instance is
+ instantiated from this VNF
+ package.
+ callbackUri:
+ description: |
+ String formatted according to IETF RFC 3986.
+ type: string
+ _links:
+ description: |
+ Links to resources related to this resource.
+ type: object
+ required:
+ - self
+ properties:
+ self:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ '400':
+ description: >
+ Bad Request
+
+ Invalid attribute-based filtering parameters or Invalid attribute
+ selector. It fhe request is malformed or syntactically incorrect
+ (e.g. if the request URI contains incorrect query parameters or a
+ syntactically incorrect payload body), the API producer shall
+ respond with this response code. The "ProblemDetails" structure
+ shall be provided, and should include in the "detail" attribute more
+ information about the source of the problem. If the request contains
+ a malformed access token, the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided. If there is
+ an application error related to the client's input that cannot be
+ easily mapped to any other HTTP response code ("catch all error"),
+ the API producer shall respond with this response code.The
+ "ProblemDetails" structure shall be provided, and shall include in
+ the "detail" attribute more information about the source of the
+ problem.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ This code is returned if the requested byte range in the Range HTTP
+ header is not present in the requested resource.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '/subscriptions/{subscriptionId}':
+ parameters:
+ - 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.
+ in: path
+ type: string
+ required: true
+ get:
+ description: |
+ Query Subscription Information
+
+ The GET method reads an individual subscription.
+ parameters:
+ - name: Accept
+ description: >
+ Content-Types that are acceptable for the response. Reference: IETF
+ RFC 7231
+ in: header
+ required: true
+ type: string
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '200':
+ description: |
+ OK
+ Representation of the subscription resource.
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ description: >
+ This type represents a subscription related to notifications about
+ VNF package management.
+ type: object
+ required:
+ - id
+ - callbackUri
+ - _links
+ properties:
+ id:
+ description: |
+ An identifier with the intention of being globally unique.
+ type: string
+ filter:
+ description: >
+ This type represents a subscription filter related to
+ notifications related to VNF package management. At a
+ particular nesting level in the filter structure, the
+ following applies: All attributes shall match in order for the
+ filter to match (logical "and" between different filter
+ attributes). If an attribute is an array, the attribute shall
+ match if at least one of the values in the array matches
+ (logical "or" between the values of one filter attribute).
+ type: object
+ properties:
+ notificationTypes:
+ description: >
+ Match particular notification types. Permitted values: -
+ VnfPackageOnboardingNotification -
+ VnfPackageChangeNotification The permitted values of the
+ "notificationTypes" attribute are spelled exactly as the
+ names of the notification types to facilitate automated
+ code generation systems.
+ type: array
+ items:
+ type: string
+ enum:
+ - VnfPackageOnboardingNotification
+ - VnfPackageChangeNotification
+ vnfProductsFromProviders:
+ description: >
+ If present, match VNF packages that contain VNF products
+ from certain providers. The attributes
+ "vnfProductsFromProviders", "vnfdId" and "vnfPkgId" are
+ alternatives to reference to particular VNF packages in a
+ filter. They should not be used both in the same filter
+ instance, but one alternative should be chosen.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProvider
+ properties:
+ vnfProvider:
+ description: |
+ Name of the VNF provider to match.
+ type: string
+ vnfProducts:
+ description: >
+ If present, match VNF packages that contain VNF
+ products with certain product names, from one
+ particular provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfProductName
+ properties:
+ vnfProductName:
+ description: |
+ Name of the VNF product to match.
+ type: string
+ versions:
+ description: >
+ If present, match VNF packages that contain
+ VNF products with certain versions and a
+ certain product name, from one particular
+ provider.
+ type: array
+ items:
+ type: object
+ required:
+ - vnfSoftwareVersion
+ properties:
+ vnfSoftwareVersion:
+ description: |
+ A Version.
+ type: string
+ vnfdVersions:
+ description: >
+ If present, match VNF packages that
+ contain VNF products with certain VNFD
+ versions, a certain software version and
+ a certain product name, from one
+ particular provider.
+ type: array
+ items:
+ description: |
+ A Version.
+ type: string
+ vnfdId:
+ description: >
+ Match VNF packages with a VNFD identifier listed in the
+ attribute. The attributes "vnfProductsFromProviders",
+ "vnfdId" and "vnfPkgId" are alternatives to reference to
+ particular VNF packages in a filter. They should not be
+ used both in the same filter instance, but one alternative
+ should be chosen.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ vnfPkgId:
+ description: >
+ Match VNF packages with a package identifier listed in the
+ attribute. May be present if the "notificationTypes"
+ attribute contains the value
+ "VnfPackageChangeNotification", and shall be absent
+ otherwise. The attributes "vnfProductsFromProviders",
+ "vnfdId" and "vnfPkgId" are alternatives to reference to
+ particular VNF packages in a filter. They should not be
+ used both in the same filter instance, but one alternative
+ should be chosen.
+ type: array
+ items:
+ description: >
+ An identifier with the intention of being globally
+ unique.
+ type: string
+ operationalState:
+ description: >
+ - ENABLED: The VNF package is enabled, i.e. it can be used
+ for
+ 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).
+ type: string
+ enum:
+ - ENABLED
+ - DISABLED
+ usageState:
+ description: >
+ - IN_USE: VNF instances instantiated from this VNF package
+ exist. - NOT_IN_USE: No existing VNF instance is
+ instantiated from this VNF
+ package.
+ callbackUri:
+ description: |
+ String formatted according to IETF RFC 3986.
+ type: string
+ _links:
+ description: |
+ Links to resources related to this resource.
+ type: object
+ required:
+ - self
+ properties:
+ self:
+ description: |
+ This type represents a link to a resource.
+ type: object
+ required:
+ - href
+ properties:
+ href:
+ description: |
+ URI of the referenced resource.
+ type: string
+ format: url
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem. If the request contains a malformed access
+ token, the API producer should respond with this response. The
+ details of the error shall be returned in the WWW-Authenticate HTTP
+ header, as defined in IETF RFC 6750 and IETF RFC 7235. The
+ ProblemDetails structure may be provided. If there is an application
+ error related to the client's input that cannot be easily mapped to
+ any other HTTP response code ("catch all error"), the API producer
+ shall respond with this response code.The "ProblemDetails" structure
+ shall be provided, and shall include in the "detail" attribute more
+ information about the source of the problem.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ This code is returned if the requested byte range in the Range HTTP
+ header is not present in the requested resource.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ delete:
+ description: |
+ Terminate subscription
+
+ The DELETE method terminates an individual subscription.
+ parameters:
+ - name: Authorization
+ description: |
+ The authorization token for the request. Reference: IETF RFC 7235
+ in: header
+ required: false
+ type: string
+ responses:
+ '204':
+ description: |
+ No Content
+ The subscription resource was deleted successfully.
+ headers:
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ type: string
+ maximum: 1
+ minimum: 0
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided, and
+ should include in the "detail" attribute more information about the
+ source of the problem. If the request contains a malformed access
+ token, the API producer should respond with this response. The
+ details of the error shall be returned in the WWW-Authenticate HTTP
+ header, as defined in IETF RFC 6750 and IETF RFC 7235. The
+ ProblemDetails structure may be provided. If there is an application
+ error related to the client's input that cannot be easily mapped to
+ any other HTTP response code ("catch all error"), the API producer
+ shall respond with this response code.The "ProblemDetails" structure
+ shall be provided, and shall include in the "detail" attribute more
+ information about the source of the problem.
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ Unauthorized
+
+ If the request contains no access token even though one is required,
+ or if the request contains an authorization token that is invalid
+ (e.g. expired or revoked), the API producer should respond with this
+ response. The details of the error shall be returned in the
+ WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
+ RFC 7235. The ProblemDetails structure may be provided.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ WWW-Authenticate:
+ description: >
+ Challenge if the corresponding HTTP request has not provided
+ authorization, or error details if the corresponding HTTP
+ request has provided an invalid authorization token.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ Forbidden
+
+ If the API consumer is not allowed to perform a particular request
+ to a particular resource, the API producer shall respond with this
+ response code. The "ProblemDetails" structure shall be provided. It
+ should include in the "detail" attribute information about the
+ source of the problem, and may indicate how to solve it.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ Not Acceptable
+
+ If the "Accept" HTTP header does not contain at least one name of a
+ content type that is acceptable to the API producer, the API
+ producer shall respond with this response code. The "ProblemDetails"
+ structure may be omitted in that case.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ This code is returned if the requested byte range in the Range HTTP
+ header is not present in the requested resource.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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.
+ 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].
+ 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".
+ type: string
+ format: URI
+ title:
+ description: >
+ A short, human-readable summary of the problem type. It should
+ not change from occurrence to occurrence of the problem,
+ except for purposes of localization. If type is given and
+ other than "about:blank", this attribute shall also be
+ provided. A short, human-readable summary of the problem
+ type. It SHOULD NOT change from occurrence to occurrence of
+ the problem, except for purposes of localization (e.g., using
+ proactive content negotiation; see [RFC7231], Section 3.4).
+ type: string
+ status:
+ description: >
+ The HTTP status code for this occurrence of the problem. The
+ HTTP status code ([RFC7231], Section 6) generated by the
+ origin server for this occurrence of the problem.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+
diff --git a/SOL003/VNFPackageManagementNotification-API_nxw/README.md b/SOL003/VNFPackageManagementNotification-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFPackageManagementNotification-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFPerformanceManagement-API_nxw/README.md b/SOL003/VNFPerformanceManagement-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFPerformanceManagement-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VNFPerformanceManagementNotification-API_nxw/README.md b/SOL003/VNFPerformanceManagementNotification-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VNFPerformanceManagementNotification-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/README.md b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL003/VirtualisedResourcesQuotaAvailableNotification-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL003/gs_nfv-sol003v020401p.pdf b/SOL003/gs_nfv-sol003v020401p.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..280e3f37e5e3c1cd3481a5aa6773e7d3c52eea9d
Binary files /dev/null and b/SOL003/gs_nfv-sol003v020401p.pdf differ
diff --git a/SOL005/NSDManagement-API_nxw/README.md b/SOL005/NSDManagement-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL005/NSDManagement-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL005/NSFaultManagement-API_egm/README.md b/SOL005/NSFaultManagement-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL005/NSFaultManagement-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL005/NSLifecycleManagement-API_egm/README.md b/SOL005/NSLifecycleManagement-API_egm/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL005/NSLifecycleManagement-API_egm/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL005/README.md b/SOL005/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL005/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL005/VNFPackageManagement-API_nxw/README.md b/SOL005/VNFPackageManagement-API_nxw/README.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5f7677f55fcf78e1846a4ff3f61fb4cdef215c3
--- /dev/null
+++ b/SOL005/VNFPackageManagement-API_nxw/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL005/gs_NFV-SOL005v020401p.pdf b/SOL005/gs_NFV-SOL005v020401p.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..25853e74037202158cee668abf38a751c7613b91
Binary files /dev/null and b/SOL005/gs_NFV-SOL005v020401p.pdf differ