diff --git a/QoDProvisioning/README.md b/QoDProvisioning/README.md index 7854ad45eeb76c6a6ebe0aaba51f53eba4716131..b61372ce14393063ebd2cc1dea02630fbd12077b 100644 --- a/QoDProvisioning/README.md +++ b/QoDProvisioning/README.md @@ -28,7 +28,7 @@ In order to support interaction with OSL’s CAMARAaaS APIs, the operator servic Still, since there are various operations that can take place (CREATE and DELETE), it is also needed a characteristic to map this. Therefore, the operator’s service must also have a characteristics titled *qodProv.operation*. The DELETE operation is achieved based on a provisioning Id, and therefore another characteristics is needed: *qodProv.provisioningId.* -Finally, it is required a characteristics to store the provisionings that were enforced by the operator’s service. We can define this characteristic as *camaraResults*. +Finally, it is required a characteristic to store the provisionings that were enforced by the operator’s service. We can define this characteristic as *camaraResults*. Therefore, for an operator’s service to be controlled by OSL’s CAMARA APIs, it needs to be designed with, at least, the following characteristics: @@ -47,7 +47,7 @@ Therefore, for an operator’s service to be controlled by OSL’s CAMARA APIs, Additional characteristics are fully supported. Those can be custom characteristics that are required by the Operator’s Service. -In regard to the *camaraResults* characteristics, to allow interoperability, it must store a Stringified JSON Array with the enforced QoD Provisionings. **The schema of each provisioning should be the one defined in CAMARA’s QoD Provisioning API Specification.** +In regard to the *camaraResults* characteristic, to allow interoperability, it must store a Stringified JSON Array with the enforced QoD Provisionings. **The schema of each provisioning should be the one defined in CAMARA’s QoD Provisioning API Specification.** ### TMF Service Characteristics of the CAMARAaaS APIs