SOL005: v2.8.1 review fixes

src/SOL005/NSDManagement/NSDManagement.yaml

@@ -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:

src/SOL005/NSFaultManagement/NSFaultManagement.yaml

@@ -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

src/SOL005/NSFaultManagementNotification/definitions/SOL005NSFaultManagementNotification_def.yaml

@@ -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

src/SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml

@@ -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

src/SOL005/NSLifecycleManagementNotification/definitions/SOL005NSLifecycleManagementNotification_def.yaml

@@ -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

src/SOL005/NSPerformanceManagementNotification/definitions/SOL005NSPerformanceManagementNotification_def.yaml

@@ -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.

src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml

@@ -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

src/SOL005/VNFPackageManagement/definitions/SOL005VNFPackageManagement_def.yaml

@@ -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