SOL005 issueshttps://forge.etsi.org/rep/nfv/SOL005/-/issues2020-09-11T11:55:26Zhttps://forge.etsi.org/rep/nfv/SOL005/-/issues/2Definition of the extLinkPortId attribute in the VnfExtCpInfo data type.2020-09-11T11:55:26ZVlademir BrusseDefinition of the extLinkPortId attribute in the VnfExtCpInfo data type.Our R&D has found an issue in SOL005 v2.6.1 and its propagation on v2.5.1, v2.7.1 and v3.3.1.
The extLinkPortId attribute of VnfExtCpInfo data type is defined as Identified in SOL005 spec and as “CpProtocolInmfo” in v2.7.1 and v3.3.1 of...Our R&D has found an issue in SOL005 v2.6.1 and its propagation on v2.5.1, v2.7.1 and v3.3.1.
The extLinkPortId attribute of VnfExtCpInfo data type is defined as Identified in SOL005 spec and as “CpProtocolInmfo” in v2.7.1 and v3.3.1 of SOL005 OpenAPI:
extLinkPortId:
description: >
Identifier of the "extLinkPortInfo" structure inside the "extVirtualLinkInfo"
structure. Shall be present if the CP is associated to a link port.
$ref: "#/definitions/CpProtocolInfo"
Should extLinkPortId definition be:
extLinkPortId:
description: >
Identifier of the "extLinkPortInfo" structure inside the "extVirtualLinkInfo"
structure. Shall be present if the CP is associated to a link port.
`$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
According to SOL005 on those versions (v2.4.1 as well) this attribute should be defined as “Identifier”, and then be translated to string.
Best Regards,
VlademirGiacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/6Mismatch between AffectedVirtualLink data type in SOL005 and as defined in ya...2020-12-08T17:54:48ZVlademir BrusseMismatch between AffectedVirtualLink data type in SOL005 and as defined in yaml file.It was found a mismatch between the SOL005 v2.7.1 and the SOL005NSLifecycleManagement_def.yaml for an attribute name of the AffectedVirtualLink data type:
AffectedVirtualLink:
description: >
This type provides information abou...It was found a mismatch between the SOL005 v2.7.1 and the SOL005NSLifecycleManagement_def.yaml for an attribute name of the AffectedVirtualLink data type:
AffectedVirtualLink:
description: >
This type provides information about added, deleted, modified and
temporary VLs.
type: object
required:
- id
- virtualLinkDescId
- changeType
- networkResource
```
The solution requires to replace the "id" attribute name with "nsVirtualLinkInstanceId" in all occurrences as defined in SOL005 v2.7.1.Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/1Swagger file: SOL005NSLifecycleManagement_def.yaml; ns_lcm_op_occ: "statusEnt...2020-12-15T05:03:17ZbanerjeesuSwagger file: SOL005NSLifecycleManagement_def.yaml; ns_lcm_op_occ: "statusEnteredTime" should be "stateEnteredTime" to match vnf_lcm_op_occThe file https://forge.etsi.org/rep/nfv/SOL005/blob/v2.7.1/src/SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml NsLcmOpOcc has "statusEnteredTime" misspelt.
It should ideally be "stateEnteredTime" to match ...The file https://forge.etsi.org/rep/nfv/SOL005/blob/v2.7.1/src/SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml NsLcmOpOcc has "statusEnteredTime" misspelt.
It should ideally be "stateEnteredTime" to match the corresponding field in VnfLcmOpOcc: https://forge.etsi.org/rep/nfv/SOL002-SOL003/blob/v2.7.1/src/definitions/SOL002SOL003VNFLifecycleManagement_def.yaml
Reference: Attached screenshot from 2.7.1 SOL005 Spec.
The description against 'statusEnteredTime' says, "Date-time when the current _state_ has been entered." Please see that it's referred to as "state" in the descriptions and other field names from NsLcmOpOcc as well, e.g. {'operationState'}. Apart from the specification language aspect, we have the below challenge from implementation and client side.
The dissimilarity of the names in SOL005 and corresponding SOL003/SOL002 model attributes may pose limitations when it comes to client-side/server-side code trying to use the JSON-Object-mapping tools (e.g. ObjectMapper) for invoking/serving APIs across NS and VNF LCM operations. The ObjectMappers need to have field transformation logic (to-and-fro) to map "statusEnteredTime" to "stateEnteredTime" and back while moving between the SOL003 and SOL005 APIs for instance.
![Screen_Shot_2020-08-21_at_11.43.35_AM](/uploads/73c67a0ec0f82a5fb40227e6d2526691/Screen_Shot_2020-08-21_at_11.43.35_AM.png)https://forge.etsi.org/rep/nfv/SOL005/-/issues/10Swagger File: VNFPackageManagement.yaml; Get '/vnf_packages' should not have ...2021-01-19T12:05:55ZjaissSwagger File: VNFPackageManagement.yaml; Get '/vnf_packages' should not have property 'VnfPkgInfo'The file:
https://forge.etsi.org/rep/nfv/SOL005/blob/v2.7.1/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml
Get '/vnf_packages' has following response:
```yaml
schema:
type: array
items:
...The file:
https://forge.etsi.org/rep/nfv/SOL005/blob/v2.7.1/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml
Get '/vnf_packages' has following response:
```yaml
schema:
type: array
items:
properties:
VnfPkgInfo:
$ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfo"
```
whereas its should be
```yaml
schema:
type: array
items:
$ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfo"
```
property 'VnfPkgInfo' is not required. Its a Data Type and not property.
Reference: Attached screenshot from 2.7.1 SOL005 Spec.
![Screen_Shot_2020-12-16_at_12.44.19_PM](/uploads/bdfb142a57c5a0c24a500452345cd293/Screen_Shot_2020-12-16_at_12.44.19_PM.png)https://forge.etsi.org/rep/nfv/SOL005/-/issues/18SOL005NSFaultManagement_def.yaml: faultDetails should be an array2021-09-28T14:56:38ZhegdesaSOL005NSFaultManagement_def.yaml: faultDetails should be an arrayPlease refer to the following line: https://forge.etsi.org/rep/nfv/SOL005/blob/master/src/SOL005/NSFaultManagement/definitions/SOL005NSFaultManagement_def.yaml#L101
`faultDetails` should be an array of strings, instead of a string.
Pag...Please refer to the following line: https://forge.etsi.org/rep/nfv/SOL005/blob/master/src/SOL005/NSFaultManagement/definitions/SOL005NSFaultManagement_def.yaml#L101
`faultDetails` should be an array of strings, instead of a string.
Page 245 of the [SOL005 specification](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/005/02.07.01_60/gs_NFV-SOL005v020701p.pdf) has the following, which indicates a cardinality on `faultDetails`:
```
| faultDetails | String | 0..N | Provides additional information about the fault. |
```https://forge.etsi.org/rep/nfv/SOL005/-/issues/17Incorrect SOL005/VNFPackageManagement/PkgmNotificationFilter schema2021-09-28T14:56:39ZSana ZulfiqarIncorrect SOL005/VNFPackageManagement/PkgmNotificationFilter schemaThe file: https://forge.etsi.org/rep/nfv/SOL005/blob/2.7.1-dev/src/SOL005/VNFPackageManagement/definitions/SOL005VNFPackageManagement_def.yaml
The Schema of "PkgmNotificationsFilter" is incorrect. According to the SOL005 specification, ...The file: https://forge.etsi.org/rep/nfv/SOL005/blob/2.7.1-dev/src/SOL005/VNFPackageManagement/definitions/SOL005VNFPackageManagement_def.yaml
The Schema of "PkgmNotificationsFilter" is incorrect. According to the SOL005 specification, Attributes vnfdId, vnfPkgId, operationalState, usageState, vnfmInfo are part of "PkgmNotificationsFilter" instead of "vnfProductsFromProviders".
The current implementation is like this:
![SOL005-pkgm](/uploads/c65ed4fe3f4c1f6e87dfed5cfe2d28da/SOL005-pkgm.PNG)
Implementation should be like that (reference v2.7.1/SOL005-9.5.3.4):
![image](/uploads/4033698f34919ad4d9e1516a334f276e/image.png)Sana ZulfiqarSana Zulfiqarhttps://forge.etsi.org/rep/nfv/SOL005/-/issues/12nsCpHandle attribute.2021-09-28T14:56:39ZVlademir BrussensCpHandle attribute.The nsCpHandle attribute with cardinality 0..1 in NsLinkPortInfo and VnffgInfo data types should have the yaml code generated as type “object” and not type “array” (as it is generated in the SOL005NSLifecycleManagement_def.yaml file of t...The nsCpHandle attribute with cardinality 0..1 in NsLinkPortInfo and VnffgInfo data types should have the yaml code generated as type “object” and not type “array” (as it is generated in the SOL005NSLifecycleManagement_def.yaml file of the SOL005 v2.7.1), because the cardinality 0..1 means that attribute is Optional and not an Array.
The NfpInfo data type also has the cpGroup attribute defined as items: $ref: "#/definitions/NsCpHandle" that should be items: $ref: "#/definitions/CpGroupInfo" as defined for NfpData.Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/28Bugzilla [Bug 260] - NsdInfoModifications: userDefinedData KeyValuePairs of w...2022-09-01T15:42:26ZVlademir BrusseBugzilla [Bug 260] - NsdInfoModifications: userDefinedData KeyValuePairs of wrong typeThis issue was reported in Bugzilla tool by Frank Bryden in 24/08/2020, as follows:
[Bug 260] NsdInfoModifications: userDefinedData KeyValuePairs of wrong type
The NsdInfoModifications datatype contains a section for showing modified u...This issue was reported in Bugzilla tool by Frank Bryden in 24/08/2020, as follows:
[Bug 260] NsdInfoModifications: userDefinedData KeyValuePairs of wrong type
The NsdInfoModifications datatype contains a section for showing modified userDefinedData. According to SOL005, this is of type KeyValuePairs. No issue there.
The OpenAPI specifies the latter datatype to be an array, when SOL013 specifies it must be an object (7.1.5 @ SOL0013v2.7.1).Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/33In NSDManagement.yaml some parameter descriptions are in schema2022-09-05T08:12:14ZkaidosIn NSDManagement.yaml some parameter descriptions are in schemaI noticed this on 2.7.1-maintenance and 2.8.1. It may be in other branches too. Judging from the other operation parameters as well as the other swagger APIs in the repo this:
```yaml
schema:
$ref: "definitions/SOL005NSDescriptorManag...I noticed this on 2.7.1-maintenance and 2.8.1. It may be in other branches too. Judging from the other operation parameters as well as the other swagger APIs in the repo this:
```yaml
schema:
$ref: "definitions/SOL005NSDescriptorManagement_def.yaml#/definitions/CreateNsdInfoRequest"
description: >
Parameters of creating an NS descriptor resource, as defined in clause 5.5.2.3.
```
Should be like this:
```yaml
schema:
$ref: "definitions/SOL005NSDescriptorManagement_def.yaml#/definitions/CreateNsdInfoRequest"
description: >
Parameters of creating an NS descriptor resource, as defined in clause 5.5.2.3.
```
This may seems superficial but it creates issues with validators/generators.
I have the diff ready but I am `not allowed to push code to this project.`