Commit f8671fbc authored by Francesca Moscatelli's avatar Francesca Moscatelli
Browse files

SOL005: v2.8.1 review fixes

parent 72ff3121
Pipeline #6779 passed with stage
in 0 seconds
......@@ -828,21 +828,27 @@ paths:
• 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 NSD; for a multi-file NSD,
a ZIP file shall be returned.
The default format of the ZIP file shall be the one specified in ETSI GS NFV-SOL 007
where only the YAML files representing the NSD, and information necessary to navigate
the ZIP file and to identify the file that is the entry point for parsing the NSD and
(if requested) further security information are included. This means that the content
of the ZIP archive shall contain the following files from the NSD archive:
• TOSCA.meta (if available in the NSD archive);
• the main service template (either as referenced from TOSCA.meta or available as a
file with the extension ".yml" or ".yaml" from the root of the archive);
• every component of the NSD referenced (recursively) from the main service template;
• the related security information, if the "include_signatures" URI parameter is provided, as follows:
- the manifest file;
- the singleton certificate file in the root of the NSD archive (if available in the NSD archive);
- the signing certificates of the individual files included in the ZIP archive
(if available in the NSD archive);
- the signatures of the individual files (if available in the NSD archive).
The default format of the ZIP file shall comply with the CSAR format as specified in ETSI GS NFV-SOL 007
where only the YAML files representing the NSD, and information necessary to navigate the ZIP file and to
identify the file that is the entry point for parsing the NSD and (if requested) further security information
are included, and other artifacts referenced from the YAML files are excluded. This means that the content of
the ZIP archive shall contain the following files from the NSD archive:
- TOSCA.meta (if available in the NSD archive);
- the main TOSCA definitions YAML file (either as referenced from TOSCA.meta or available as a file with the
extension ".yml" or ".yaml" from the root of the archive);
- every component of the NSD referenced (recursively) from the main TOSCA definitions YAML file;
NOTE 1: For a NSD based on TOSCA, it includes all the imported type definition files as indicated in the top
level service template and in any of the lower level service template if it has any as described in ETSI GS NFV-SOL 001.
NOTE 2: For a NSD based on YANG, it includes the file as indicated by the "yang_definitions" keyname in the metadata
section of the main yaml file as described in ETSI GS NFV-SOL 007.
- the related security information, if the "include_signatures" URI parameter is provided, as follows:
- the manifest file;
- the singleton certificate file in the root of the NSD archive (if available in the NSD archive);
- the signing certificates of the individual files included in the ZIP archive
(if available in the NSD archive);
- the signatures of the individual files (if available in the NSD archive).
This method shall follow the provisions specified in the Tables 5.4.4a.3.2-1 and 5.4.4a.3.2-2 for
URI query parameters, request and response data structures, and response codes.
parameters:
......
......@@ -324,20 +324,20 @@ paths:
406:
$ref: "../responses/SOL005_resp.yaml#/responses/406"
409:
description: >
409 CONFLICT
#description: >
# 409 CONFLICT
Shall be returned upon the following error: The
operation cannot be executed currently, due to a
conflict with the state of the "Individual alarm"
resource.
Typically, this is due to the fact that the alarm is
already in the state that is requested to be set (such
as trying to acknowledge an already-acknowledged
alarm).
The response body shall contain a ProblemDetails
structure, in which the "detail" attribute shall convey
more information about the error.
# Shall be returned upon the following error: The
# operation cannot be executed currently, due to a
# conflict with the state of the "Individual alarm"
# resource.
# Typically, this is due to the fact that the alarm is
# already in the state that is requested to be set (such
# as trying to acknowledge an already-acknowledged
# alarm).
# The response body shall contain a ProblemDetails
# structure, in which the "detail" attribute shall convey
# more information about the error.
$ref: "../responses/SOL005_resp.yaml#/responses/409"
412:
$ref: "../responses/SOL005_resp.yaml#/responses/412"
......@@ -371,8 +371,8 @@ paths:
The POST method creates a new subscription.
This method shall follow the provisions specified in the Tables 8.4.4.3.1-1 and 8.4.4.3.1-2 for URI query
parameters, request and response data structures, and response codes.
As the result of successfully executing this method, a new "Individual subscription" resource shall exist
as defined in clause 8.4.5. This method shall not trigger any notification.
As the result of successfully executing this method, a new "Individual subscription" resource as defined in
clause 8.4.5 shall have been created. This method shall not trigger any notification.
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 OSS, and might make sense only in very rare
use cases. Consequently, the NFVO may either allow creating a subscription resource if another subscription
......
......@@ -119,7 +119,8 @@ definitions:
description: >
This type represents a notification that the alarm list has been rebuilt, e.g. if the NFVO detects its storage holding the
alarm list is corrupted. It shall comply with the provisions defined in Table 8.5.2.7-1.
The notification shall be triggered by the NFVO when the alarm list has been rebuilt.
The notification shall be triggered by the NFVO when the alarm list has been rebuilt,
e.g. because the NFVO has detected that its storage holding the alarm list was corrupted.
type: object
required:
- id
......
......@@ -404,8 +404,6 @@ definitions:
Identifier of information held by the NFVO about
the specific VNF package on which the VNF is
based. This identifier has been allocated by the NFVO.
This attribute can be modified with the PATCH
method.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
vnfConfigurableProperties:
description: >
......@@ -548,38 +546,28 @@ definitions:
$ref: "#/definitions/VirtualStorageResourceInfo"
metadata:
description: >
Additional VNF-specific attributes that provide
metadata describing the VNF instance.
Metadata that are writeable are declared in the
VNFD (see note 2).
These attributes represent values that are
stored persistently in the VnfInstance structure
for consumption by functional blocks that
invoke the VNF lifecycle management
interface. They are not consumed by the
VNFM, or the lifecycle management scripts.
Modifying the values of these attributes has no
effect on the VNF instance, it only affects the
information represented in the VnfInstance
structure.
Metadata that the VNF provider foresees are
expected to be declared in the VNFD (see note 2).
Modifications to these attributes can be
requested using the "ModifyVnfInfoData" structure.
Additional VNF-specific attributes that provide metadata describing the VNF instance.
These attributes represent values that are stored persistently in the VnfInstance structure
for consumption by functional blocks that invoke the VNF lifecycle management interface.
They are not consumed by the VNFM, or the lifecycle management scripts.
Modifying the values of these attributes has no effect on the VNF instance, it only affects
the information represented in the VnfInstance structure.
Metadata that the VNF provider foresees are expected to be declared in the VNFD (see note 2).
Modifications to these attributes can be requested using the "ModifyVnfInfoData" structure.
NOTE 2: ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.
$ref: "../../definitions/SOL005_def.yaml#/definitions/KeyValuePairs"
extensions:
description: >
Additional VNF-specific attributes that affect the lifecycle management of this VNF instance.
These attributes represent values that are stored persistently in the VnfInstance structure
for consumption by the VNFM, or by the lifecycle management scripts. during the execution
of VNF lifecycle management operations.
Modifying the values of these attributes has no direct effect on the VNF instance; however,
the modified attribute values can be considered during subsequent VNF lifecycle management
operations, which means that the modified values can indirectly affect the configuration of the VNF instance.
These attributes represent values that are stored persistently in the VnfInstance structure for
consumption by the VNFM or by the lifecycle management scripts during the execution of VNF lifecycle
management operations.
Modifying the values of these attributes has no direct effect on the VNF instance; however, the modified
attribute values can be considered during subsequent VNF lifecycle management operations, which means that
the modified values can indirectly affect the configuration of the VNF instance.
All extensions that are allowed for the VNF are declared in the VNFD.
Modifications to these attributes can be
requested using the "ModifyVnfInfoData" structure.
ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.
Modifications to these attributes can be requested using the "ModifyVnfInfoData" structure.
$ref: "../../definitions/SOL005_def.yaml#/definitions/KeyValuePairs"
LccnLinks:
......@@ -3618,10 +3606,10 @@ definitions:
to a given level, or to scale a VNF instance by steps.
type: object
required:
- vnfInstanceid
- vnfInstanceId
- scaleVnfType
properties:
vnfInstanceid:
vnfInstanceId:
description: >
Identifier of the VNF instance being scaled.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
......@@ -3796,7 +3784,8 @@ definitions:
LcmOpNameForChangeNotificationType:
description: >
The enumeration LcmOpNameForChangeNotificationType represents the name of the lifecycle operation that impacts the NS component and trigger an NS change notification. It shall comply with the provisions defined in Table 6.5.4.6-1.
The enumeration LcmOpNameForChangeNotificationType represents the name of the lifecycle operation that impacts the NS component and
trigger an NS change notification. It shall comply with the provisions defined in Table 6.5.4.6-1.
Value | Description
------|------------
VNF_INSTANTIATE | Represents the "Instantiate VNF" LCM operation.
......@@ -3839,7 +3828,8 @@ definitions:
------|------------
START | The impact on the NS component is identified.
COMPLETED | The impact on the NS component stops and related lifecycle operation completes successfully.
PARTIALLY_COMPLETED | The impact on the NS component stops and related lifecycle operation partially completes. Inconsistency state may exist on the NS component.
PARTIALLY_COMPLETED | The impact on the NS component stops and related lifecycle operation partially completes.
Inconsistency state may exist on the NS component.
FAILED | The impact on the NS component stops and related lifecycle operation fails. Inconsistency state may exist for the NS component.
ROLLED_BACK | The impact on the NS component stops and related lifecycle operation is rolled back.
type: string
......@@ -4301,8 +4291,6 @@ definitions:
* At least one of these attributes shall be present for a
to-be-created external CP instance or an existing external
CP instance.
* If the "linkPortId" attribute is absent, the VNFM shall create a
link port.
* If the "cpProtocolData" attribute is absent, the "linkPortId"
attribute shall be provided referencing a pre-created link port,
and the VNFM can use means outside the scope of the present
......@@ -4324,8 +4312,6 @@ definitions:
* At least one of these attributes shall be present for a
to-be-created external CP instance or an existing external
CP instance.
* If the "linkPortId" attribute is absent, the VNFM shall create a
link port.
* If the "cpProtocolData" attribute is absent, the "linkPortId"
attribute shall be provided referencing a pre-created link port,
and the VNFM can use means outside the scope of the present
......
......@@ -165,7 +165,9 @@ definitions:
$ref: "../../definitions/SOL005_def.yaml#/definitions/DateTime"
nsInstanceId:
description: >
The created NS instance identifier
The created NS instance identifier. Shall be set to the same "id"
attribute value of the associated "NsInstance" representation of
the "Individual NS instance" resource.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
_links:
description: >
......@@ -205,7 +207,7 @@ definitions:
$ref: "../../definitions/SOL005_def.yaml#/definitions/DateTime"
nsInstanceId:
description: >
The created NS instance identifier. Shall be set to the
The deleted NS instance identifier. Shall be set to the
same "id" attribute value of the associated "NsInstance"
representation of the "Individual NS instance" resource.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
......@@ -276,7 +278,7 @@ definitions:
associated to the notification and
impacts the NS component directly or
indirectly.
$ref: "#/definitions/LcmOpNameForChangeNotificationType"
$ref: "../../NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml#/definitions/LcmOpNameForChangeNotificationType"
lcmOpOccStatusImpactingNsComponent:
description: >
Indicates this status of the lifecycle
......@@ -284,7 +286,7 @@ definitions:
associated to the notification and
impacts the NS component directly or
indirectly.
$ref: "#/definitions/LcmOpOccStatusForChangeNotificationType"
$ref: "../../NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml#/definitions/LcmOpOccStatusForChangeNotificationType"
notificationType:
description: >
Discriminator for the different
......
......@@ -40,7 +40,7 @@ definitions:
pmJobId:
description: >
Identifier of the PM job for which performance information is available.
type: string
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
objectType:
description: >
Type of the measured object.
......
......@@ -246,9 +246,7 @@ paths:
schema:
type: array
items:
properties:
VnfPkgInfo:
$ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfo"
$ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfo"
400:
$ref: "../responses/SOL005_resp.yaml#/responses/400"
401:
......@@ -403,9 +401,7 @@ paths:
maximum: 1
minimum: 1
schema:
properties:
VnfPkgInfoModifications:
$ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfoModifications"
$ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfoModifications"
400:
$ref: "../responses/SOL005_resp.yaml#/responses/400"
401:
......@@ -495,20 +491,105 @@ paths:
description: >
The GET method reads the content of the VNFD within a VNF package.
The default format of the ZIP archive shall be the one specified in ETSI GS NFV-SOL 004 [5] where only the files
representing the VNFD and information necessary to navigate the ZIP file and to identify the file that is the entry point
for parsing the VNFD and (if requested) further security information are included. This means that the structure of the
ZIP archive shall correspond to the directory structure used in the VNF package and that the archive shall contain the
following files from the package:
• TOSCA.meta (if available in the package).
• The main TOSCA definitions YAML file (either as referenced from TOSCA.meta or available as a file with
the extension ".yml" or ".yaml" from the root of the archive).
Every component of the VNFD referenced (recursively) from the main TOSCA definitions YAML file.
• The related security information, if the "include_signatures" URI parameter is provided, as follows:
- the manifest file;
- the singleton certificate file in the root of the VNF package (if available in the package);
- the signing certificates of the individual files included in the ZIP archive (if available in the package);
- the signatures of the individual files (if available in the package).
The VNFD is implemented as a collection of one or more files. A ZIP archive embedding these
files shall be returned when reading this resource.
The default format of the ZIP archive shall comply with the CSAR format as specified in ETSI
GS NFV-SOL 004 where only the files representing the VNFD and information needed to navigate
the ZIP archive and to identify the file that is the entry point for parsing the VNFD and (if requested)
further security information are included, and software images as well as other artifacts referenced
from the YAML files are excluded. This means that the structure of the ZIP archive shall correspond
to the directory structure used in the VNF package and that the archive shall contain the following
files from the package:
- TOSCA.meta (if available in the package).
- The main TOSCA definitions YAML file (either as referenced from TOSCA.meta or available as a file
with the extension ".yml" or ".yaml" from the root of the archive).
- Every component of the VNFD referenced (recursively) from the main TOSCA definitions YAML file.
NOTE 1: For a VNFD based on TOSCA, it includes all the imported type definition files as indicated
in the top level service template and in any of the lower level service template if it has any as
described in ETSI GS NFV-SOL 001.
NOTE 2: For a VNFD based on YANG, it includes the file as indicated by the "yang_definitions" keyname
in the metadata section of the main yaml file as described in ETSI GS NFV-SOL 004.
- The related security information, if the "include_signatures" URI parameter is provided, as follows:
- the manifest file;
- the singleton certificate file in the root of the VNF package (if available in the package);
- the signing certificates of the individual files included in the ZIP archive (if available in the package);
- the signatures of the individual files (if available in the package).
Tree examples are provided below.
NOTE 3: These examples do not show the security related files.
EXAMPLE 1: Assuming a request is sent for the following VNF package (as described in clause A.1 in ETSI GS NFV-SOL 004):
!------TOSCA-Metadata
!------TOSCA.meta (metadata for navigating the ZIP file)
!------Definitions
!----- MRF.yaml (main VNFD file)
!----- OtherTemplates (e.g. type definitions referenced by the main VNFD file)
!------Files
!----- ChangeLog.txt
!----- image(s)
!----- other artifacts
!------Tests
!----- file(s)
!------Licenses
!----- file(s)
!------Scripts
!----- install.sh
!----- MRF.mf
The NFVO will return a ZIP file of the following format:
!------TOSCA-Metadata
!------TOSCA.meta
!------Definitions
!----- MRF.yaml
!----- OtherTemplates
EXAMPLE 2: Assuming a request is sent for the following VNF package (a VNF package without a TOSCA Metadata directory,
as described in clause A.2 in ETSI GS NFV-SOL 004):
!------MRF.yaml (main VNFD file)
!------MRF.mf
!------ChangeLog.txt
!------Tests
!----- file(s)
!------Licenses
!----- file(s)
!------Artifacts
!----- install.sh
!----- start.yang
The NFVO will return a ZIP file of the following format:
!------MRF.yaml
EXAMPLE 3: Assuming a request is sent for the following VNF package (a VNF package with the YANG VNFD without a
TOSCA-Metadata directory, as described in clause A.3 in ETSI GS NFV SOL 004):
!----CompanyVNFD.yaml
!----CompanyVNFD.xml
!----CompanyVNFD.mf
!----ChangeLog.txt
!-----Files
!-----Instance Data Files
!----start.xml
!-----Licenses
!-----Scripts
!-----install.sh
The NFVO will return a ZIP file of the following format:
!----CompanyVNFD.yaml
!----CompanyVNFD.xml (indicated in the yang_definitions metadata in CompanyVNFD.yaml)
parameters:
- name: Accept
description: >
......@@ -982,7 +1063,7 @@ paths:
503:
$ref: "../responses/SOL005_resp.yaml#/responses/503"
put:
summary: Upload a VNF package by providing the content of the VNF package.
summary: The PUT method uploads the content of a VNF package.
description: >
The PUT method uploads the content of a VNF package.
This method shall follow the provisions specified in the
......@@ -992,7 +1073,9 @@ paths:
structure to "UPLOADING". Upon successful upload of the package, if the package references external artifacts, the
NFVO shall obtain the external artifacts. Subsequently, upon success, the NFVO shall set that attribute to
"PROCESSING" and shall process the package, which shall include checking package consistency. Upon successful
processing, the NFVO shall set the "onboardingState" attribute to "ONBOARDED". If an error occurs during uploading
processing, the NFVO shall set the "onboardingState" attribute to "ONBOARDED", the "operationalState" attribute to
"ENABLED", and the "usageState" attribute to "NOT_IN_USE". In addition, the NFVO shall set the value of the attributes
in the "VnfPkgInfo" that are copied from the VNFD (refer to clause 9.5.2.5). If an error occurs during uploading
the package, downloading the external artifacts or processing the package, the NFVO shall set the "onboardingState"
attribute to "ERROR" and shall populate the "onboardingFailureDetails" attribute in "VnfPkgInfo".
consumes:
......@@ -1085,7 +1168,9 @@ paths:
inclusion/exclusion defined below, embedded in a directory structure being the same as in the VNF package.
The criteria for exclusion/inclusion of an artifact in the archive are defined as follows:
• Artifacts that are software images shall be excluded from the archive.
• Artifacts that are external to the VNF package shall be excluded from the archive.
• Artifacts that are not software images and that are external to the VNF package shall be excluded from the
archive unless the URI query parameter "include_external_artifacts" has been provided.
External artifacts shall be included in the archive using the content of the "artifactPath" attribute as the path.
• All additional artifacts included in the VNF package that are MANO artifacts shall be included in the archive,
unless the URI query parameter "exclude_all_mano_artifacts" has been provided, in which case such artifacts
shall be excluded.
......@@ -1141,7 +1226,7 @@ paths:
Flag (i.e. parameter without value) that instructs the NFVO to
exclude the set of additional MANO artifacts (i.e. those that are
not images) from the response payload body.
The NFVO shall support this parameter. The VNFM may supply
The NFVO shall support this parameter. The OSS/BSS may supply
this parameter.
- name: exclude_all_non_mano_artifacts
in: query
......@@ -1151,8 +1236,18 @@ paths:
Flag (i.e. parameter without value) that instructs the NFVO to
exclude the set of non-MANO artifacts from the response payload
body.
The NFVO shall support this parameter. The VNFM may supply
this parameter.
The NFVO shall support this parameter. The OSS/BSS may supply
this parameter.
- name: include_external_artifacts
description: >
Flag (i.e. parameter without value) that instructs the NFVO to include
external artifacts in the response payload body. It shall not be treated
as an error if this flag is provided but there is no external artifact to
include in the result. If this parameter is missing, no external artifacts
shall be included.
The NFVO shall support this parameter. The OSS/BSS may supply this parameter.
in: query
type: string
- name: select_non_mano_artifact_sets
in: query
required: false
......@@ -1162,7 +1257,7 @@ paths:
which the artifacts are to be included in the response body.
The NFVO should support this parameter. If the NFVO does not
support this parameter, it shall ignore it, i.e. provide a response as
if no parameter was provided. The VNFM may supply this
if no parameter was provided. The OSS/BSS may supply this
parameter.
responses:
200:
......@@ -1268,7 +1363,9 @@ paths:
to "UPLOADING". Upon successfully obtaining the package, if the package references external artifacts, the NFVO
shall obtain the external artifacts. Subsequently, upon success, the NFVO shall set that attribute to "PROCESSING" and
shall process the package, which shall include checking package consistency. Upon successful processing, the NFVO
shall set the "onboardingState" attribute to "ONBOARDED". If an error occurs during obtaining the package,
shall set the "onboardingState" attribute to "ONBOARDED", the "operationalState" attribute to "ENABLED", and the
"usageState" attribute to "NOT_IN_USE". In addition, the NFVO shall set the value of the attributes in the "VnfPkgInfo"
that are copied from the VNFD (refer to clause 9.5.2.5). If an error occurs during obtaining the package,
downloading the external artifacts or processing the package, the NFVO shall set the "onboardingState" attribute to
"ERROR" and shall populate the "onboardingFailureDetails" attribute in "VnfPkgInfo".
parameters:
......@@ -1358,7 +1455,7 @@ paths:
- name: artifactPath
description: >
For an artifact contained as a file in the VNF package, this variable shall contain a sequence of
one or path segments representing the path of the artifact within the VNF package, relative to
one or more path segments representing the path of the artifact within the VNF package, relative to
the root of the package. See note 3.
EXAMPLE: foo/bar/m%40ster.sh
For an external artifact represented as a URI in the VNF package manifest, this variable shall
......@@ -1545,15 +1642,15 @@ paths:
The POST method creates a new subscription.
This method shall follow the provisions specified in the Tables 9.4.8.3.1-1 and 9.4.8.3.1-2 for URI
query parameters, request and response data structures, and response codes.
As the result of successfully executing this method, a new "Individual subscription" resource shall exist
as defined in clause 9.4.9. This method shall not trigger any notification.
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 OSS, 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).
As the result of successfully executing this method, a new "Individual subscription" resource as defined
in clause 9.4.9 shall have been created. This method shall not trigger any notification.
Creation of two "Individual subscription" resources with the same callback URI and the same filter can
result in performance degradation and will provide duplicates of notifications to the OSS/BSS, and might
make sense only in very rare use cases. Consequently, the NFVO may either allow creating a new "Individual
subscription" resource if another "Individual subscription" resource with the same filter and callback URI
already exists (in which case it shall return the "201 Created" response code), or may decide to not create
a duplicate "Individual subscription" resource (in which case it shall return a "303 See Other" response
code referencing the existing "Individual subscription" resource with the same filter and callback URI).
parameters:
- name: Accept
description: >
......@@ -1586,8 +1683,7 @@ paths:
The response body shall contain a representation
of the created "Individual subscription" resource.
The HTTP response shall include a "Location"
HTTP header that points to the created
subscription resource.
HTTP header that points to the created resource.
headers:
Content-Type:
description: The MIME type of the body of the response.
......@@ -1645,11 +1741,11 @@ paths:
required: false
type: string
description: >
Attribute-based filtering expression according to clause 5.2 of ETSI GS NFV SOL 013.
The NFVO shall support receiving this filtering parameter as part of the URI query string.
The OSS/BSS may supply this filtering parameter.
Attribute-based filter expression according to clause 5.2 of ETSI GS NFV SOL 013.
The NFVO shall support receiving this parameter as part of the URI query string.
The OSS/BSS may supply this parameter.
All attribute names that appear in the PkgmSubscription and in data types referenced from it
shall be supported by the NFVO in the filtering expression
shall be supported by the NFVO in the filter expression
- name: nextpage_opaque_marker
in: query
required: false
......@@ -1732,7 +1828,7 @@ paths:
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
creating a new "Individual subscription" resource. It can also be retrieved from
the "id" attribute in the payload body of that response.
in: path
type: string
......
......@@ -150,7 +150,7 @@ definitions:
$ref: "../../definitions/SOL005_def.yaml#/definitions/Link"
vnfd:
description: >
Link to the VNFD resource.
Link to the "VNFD in an individual VNF package" resource.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Link"
packageContent:
description: >
......@@ -159,7 +159,7 @@ definitions:
VnfPackageArtifactInfo:
description: >
This type represents an artifact other than a software image which is contained in a VNF package.
This type represents an artifact other than a software image which is contained in or external to a VNF package.
It shall comply with provisions defined in Table 9.5.3.3-1.
required:
- isEncrypted
......@@ -175,7 +175,7 @@ definitions:
attribute shall start with the name of the first segment in
the path in the package, i.e. it shall not be prefixed by
path separator characters such as "." and "/".
EXAMPLE: foo/bar/m@ster
EXAMPLE: foo/bar/m@ster.sh
For an external artifact represented as a URI in the VNF
descriptor, this attribute shall be present if the artifact has
been downloaded by the NFVO and shall be absent
......@@ -198,6 +198,18 @@ definitions:
description: >
Checksum of the artifact file.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Checksum"
isEncrypted:
description: >
Reflects whether the artifact is encrypted (true) or not (false).
type: boolean
nonManoArtifactSetId:
description: >
Non-MANO artifact set identifier of the non-MANO artifact
set to which the artifact belongs, as defined in
clause 4.3.7 of ETSI GS NFV-SOL 004 [5]. Shall be
provided if the artifact is a non-MANO artifact, and shall
be omitted otherwise.
type: string
artifactClassification:
description: >
Marks specific types of artifacts as defined in the VNF
......@@ -215,18 +227,6 @@ definitions:
- HISTORY
- TESTING
- LICENSE
isEncrypted:
description: >
Reflects whether the artifact is encrypted (true) or not (false).
type: boolean
nonManoArtifactSetId: