Hi Vikas and Pete
You may be interested to know that the Open API architecture team is working on revising and standardizing the characteristic pattern across all the places it is used in the API model. The enhancement is to allow declaration of characteristics with strongly-defined data types (string, integer, complex object, etc.). This is expected to be published in the design guidelines for release 18.5, but we cannot commit that all the API specs will be updated to the pattern in this release. You might want to reach out to
@Mariano Belaunde to find more details and see if this helps answer the issues you raised.
I didn't understand the point about the JSON payload - all the Open APIs have JSON payloads, and intermediate layers (such as API gateways, load balancers, etc.) would be expected to pass through untouched (apart from possible modifications to embedded URLs that might be needed).
------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------
Original Message:
Sent: Jul 17, 2018 19:43
From: Pete Bains
Subject: TMF640: Dynamic serviceCharacteristics
Hi Vikas,
With regards to your 1st question, it seems that there is some inconsistency in the way ServiceCharacteristics is represented in TMF640 & 641 - if you look at the example in 641 you will see that ServiceCharacteristics is shown with a Type & Value... in my opinion the way the service characteristics are shown across the two documents should be consistent.
I'm not 100% sure what you are referring to in your second question, but the way i understand service specifications is that you have a Customer Facing Specification (CFS) and Resource Facing Specification (RFS) that can contain the same details but can be translated or interpreted. In addition to this there is also a Configuration data structure (not in TMF640/641 but in the SID model) that will allow you to support specific configuration for your services.
Hope this helps
Pete
------------------------------
Pete Bains
Original Message:
Sent: Jul 15, 2018 21:16
From: Vikas Kumar
Subject: TMF640: Dynamic serviceCharacteristics
Hello
As per the TMF 640: ServiceCharacteristics is defined as
A name/value pair list used to store instance specific values of attributes. the behavior is equivalent to a MAP data structure where only one entry for any given value of "name" can exist
Questions:
1/ Why cant we abstract the Instance specific values & type of attributes - to allow dynamic payload?
example: use JSON object for instance specific values.
2/ Why cant we reduce the complexity of parsing?
example: Orchestrator will need to understand the instance specific attributes to parse the attributes before sending it to the network layer.
Different domains might have different instance specification attributes. Parsing or understanding the complex service construct (instance) will NOT be efficient design when scaling up millions of service activations. Whilst, using JSON object - it can be a passthrough for most Orchestrator or gateways.
Thanks
Vikas Kumar
vikkumar@ciena.com
------------------------------
Vikas Kumar
Blueplanet
Ciena Corporation
------------------------------