Open APIs

 View Only

  • 1.  TMF-645 Compliance of Internal SQ API

    Posted Sep 03, 2024 12:42
      |   view attached

    Hi, 

    I am looking for  suggestion/feedback on the compliance to TMF 645 API specifications. We are remodelling our Internal SQ API to align to TMF-645 Compliant specifications. We have implemented the mappings and converted our Internal SQ API response into TMF 645 compliant response. 

    Internal SQ API returns us below details which have been mapped to their corresponding TMF-645 API Response objects 

    TMF-645 API Response Object Data mapped from Internal SQ API 
    service.SupportingResource[] Infrastructure details at that location for the desired serviceType,free ports,type of port,Network Termination Device details ,portBandwidth ,deviceId 
    service.SupportingService[] Active Services available at that location for the desired serviceType ,associated Network Termination Device ID,Port Id 
    service.feature[].Constraint[] Any factor which creates a shortfall for provisioning a service at that location like Congestion associated with Fixed Wireless cell
    service.ServiceCharacteristics{} Speed related attributes associated to the service
    service.feature[] any features associated with the service like Speed tiers,Traffic classes and Multicast,Network Coexistence 
    service() general details associated with a service like availability state and Availability Reason and readyForService Date 


    We need to return all the fields from the Internal SQ API in TMF-645 Compliant format back to calling application to which we have exposed our TMF-645 API . 
    Need your feedback on the mapping which we have implemented,attached sample mock response for your reference.



    ------------------------------
    Arun Krishnamoorthy
    Telstra Corporation
    ------------------------------

    Attachment(s)

    txt
    TMF-645_Mapping.txt   7 KB 1 version


  • 2.  RE: TMF-645 Compliance of Internal SQ API

    Posted Sep 04, 2024 01:58

    Hi Arun,

    I took a brief look at the response. It is not quite compliant, as far as I can see. The supportingService should be a ServiceRefOrValue, and so values like ntdLoc should be represented as serviceCharacteristics, etc.

    Features are really groups of characteristics (by the featureCharacteristic relation) and I interpret isEnabled as a general indication of the relevance of the characteristics associated with the feature, and not as a way of representing boolean type characteristics.

    The ResourceRef should be just an id, href and name of a resource that can be looked up in the resource inventory, but it should not disclose any interpretable information about the resource. The responses from TMF645 can in some cases be seen by third parties (resellers, call-centers, etc) who are not necessarily authorized to know the internal resource structure, and the information you include does, as far as I can see, disclose potentially sensitive information.

    Note, that I haven't actually passed your sample through the formal compliance tool - these are just some things that catch my eye.



    ------------------------------
    Peter Bruun
    Hewlett Packard Enterprise
    ------------------------------



  • 3.  RE: TMF-645 Compliance of Internal SQ API

    Posted Sep 05, 2024 00:50

    I do interpret featureSpecification.isEnabled as the method of representing simple features which are either enabled or not.

    A similar issue came up recently about Characteristics. In a simple case characteristicSpecification.valueType is all that is needed, no characteristicSpecification.characteristicValueSpecification required.

    If I'm wrong I'd certainly like to know about it!



    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message


Related Content