1. Table of Contents
2. Project Overview
Developing best practices and standards in certain fields greatly benefits from frequent joint work or exchange of live collaboration materials with other TM Forum projects. To facilitate low-friction collaboration between such projects, this RAND Project Charter is a member of a larger “Core Project Area” which holds the RAND Project Charters.
The Core IPR Container Project Charter may be seen here; Core Project Area Charter (R18.0)
One of the most important parts that the Forum provides is a set of standard interfaces that enable rapid, repeatable, and flexible integration among operations and management systems.
- Reduce full lifecycle costs of networks and services through use of well documented, consistent interfaces
- Integrate management systems with each other while minimizing cost and risk
- Reduce cycle time for putting new network equipment in service with shorter management system integration and test cycles
- Reduce cycle time for getting new services to market with repeatable management systems integration
- Reduce development costs for adding new management capabilities with developer kits and reusable designs and code
- Easily share management information across departments, subsidiaries or with partners
The work of the Open API Project is to provide APIs that allow simple and coherent management of any given service and provide developers key design patterns to enable rapid implementation across both the members of the Forum as well as the larger digital ecosystems outside of TM Forum.
Migration of machine readable artifacts to Apache 2.0 license mode in R18.0
It is the TM Forum’s intent to re-issue the existing TM Forum Open APIs under Apache 2.0. Per the Bylaws, we have created a new project and ask all software contributors to existing APIs to join this area with the knowledge that the resulting APIs will be published with Apache 2.0 license. The APIs will be up versions and new notice and licensing statements added.
The human readable artifacts (Open API Specifications, Conformance Profiles and SID mapping documents) will continue to be published under the RAND license mode from work carried out under this charter.
Computer readable artifacts (Swagger files, Postman files, RI/CTKs) will henceforth be published under the Apache 2.0 license mode under a related but different charter, see: API Apache 2.0 Project (R18.0)
Both sets of artifacts will be consumable from one place, in the Open API portal, here: Open API Table
3. User Stories
Provide a high-level description of how an end-user might use the output of the project.
If desired, copy and paste the table below to create multiple instances of the table and complete it for each user story.
| As a.. | |
| I need to... | |
| So that I can... | |
| To do this I need... |
| As a.. | TMF member |
| I need to... | have a standard means to monitor performance, bill and settle accounts, on-board new partners, order and provision services, and so on |
| So that I can... | move quickly in the market and work with the broadest set of vendors, partners and channels |
| To do this I need... | a complete set of easily adoptable APIs that are common across both the TMF community and the broader IT ecosystem |
| As a.. | OTT developer |
| I need to... | extend my solutions into a number of TM Forum members |
| So that I can... | bring existing and new products and services to a broad market |
| To do this I need... | a rich set of APIs that provide a standard and reasonable means to integrate the various business systems |
| As a.. | TMF member |
| I need to... | be able to work with all the APIs provided by TM Forum in a consistent and expected manner |
| So that I can... | contain costs and deliver solutions in the shortest time possible |
| To do this I need... | the APIs from TM Forum to be consistent and follow common patterns that are generally adopted across the wider developer community |
4. Dependencies
Add in other projects and Frameworx dependencies this project will have. Please enter if your project will require INPUT FROM, produce OUTPUT TO or require JOINT WORKING with the named projects/Frameworx. In the COMMENTS column describe the nature of the input, output or joint working.
| Project Name | INPUT FROM / OUTPUT TO / JOINT WITH | COMMENTS (describe nature of Input / Output / Joint) | API Contact | Other Project Contact |
|---|---|---|---|---|
| API-Apache 2.0 | O | API specifications team approved and published to the API-Apache 2.0 project where the Swagger, Postman, RI and CTKs will be constructed | ||
Analytics | x | |||
| Customer Centricity | x | |||
| DMMM | x | |||
| ODA |
|
| ||
| Frameworx | Joint | To cover governance | ||
| Metrics | x | |||
| IoE | x - nothing in R17.5 | Blockchain lab? - Is there scope for complementary work? - Future work | Andreas Polz | |
| Smart City | x | Andreas Polz | Washington Tavares | |
| ZOOM + Hybrid Network Platform | IOJ | Joint calls set up with API & ZOOM |
5. Participants
This section identifies the human resources and skills required by the project to successfully deliver the items listed in this charter. Unless otherwise noted, the level of commitment of all project participants is Best Effort.
At the time the charter is written, the individuals listed below are considered tentative participants. When the charter is approved, the tentative participants will be notified and they can “join” the project in the online community. From that point forward the project resources will be maintained and viewable in real time.
* indicates that this is a required field or role.
| Role | Name* | Company* | Confluence “@” mention | Comments |
|---|---|---|---|---|
| Project Co-Team Lead | Andreas Polz | Infonova | ||
| Mentor | Pierre Gauthier | TM Forum | ||
| Sponsor* | Laurent Leboucher | Orange | ||
| Subject Matter Expert | Pierre Gauthier | TM Forum | ||
| Staff | Joann O'Brien | TM Forum |
Role Descriptions & Responsibilities given in section 11
6. Project Workstreams and Deliverables
The project workstreams and deliverables for this project are introduced in the sections below.
6.01: API Design Guidelines
Workstream Leader: Vance Shipley, Pierre Gauthier, Stephen Harrop
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.01.1 | API Design Guidelines 4.0 | TMF630 | DG4.0 - support for messaging & streaming | ||||||
| 6.01.2 | New swagger template | ||||||||
| 6.01.3 | Tie in the Tosca service definition with our catalogue management APIs |
6.02: API Processes & Governance
Workstream Leader: Stephen Harrop
How do we manage the wide spread of demands, priorities and resource challenges to optimise the delivery and maintenance of the TM Forum Open APIs?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.02.1 | Need to tie up the technical architecture with stronger governance - all deliverables - 25% have no postman - clear plan & priority to complete existing and clarity of requirements for new ones. |
6.03: Road mapped APIs
Workstream Leader: Andreas Polz
How do we ensure that the TM Forum Open APIs, planned to be developed in the API roadmap, are brought to full implementation; spec, CP, SID mapping, swagger, postman, RI & CTK?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.03.1 | Priority APIs from API roadmap - Clear plans & delivery of all the each step & product ownership to execute on full deliverable set | ||||||||
| 6.03.2 | Trouble Ticket | TMF621 - stretch | Provides a standardized client interface to Trouble Ticket Management Systems for creating, tracking and managing trouble tickets among partners as a result of an issue or problem identified by a customer or another system. Examples of Trouble Ticket API clients include CRM applications, network management or fault management systems, or other trouble ticket management systems (e.g. B2B). | L: Jacob C: Luis C: Ludovic M: [email protected] | |||||
| 6.03.3 | Customer Management | TMF629 - stretch | Provides a standardized mechanism for customer and customer account management, such as creation, update, retrieval, deletion and notification of events. | L: [email protected] M: [email protected]@accenture.com | |||||
| 6.03.4 | Party Management | TMF632 - stretch | Provides standardized mechanism for party management such as creation, update, retrieval, deletion and notification of events. Party can be an individual or an organization that has any kind of relation with the enterprise. | L: [email protected] M: [email protected] | |||||
| 6.03.5 | Product Inventory Management | TMF637 - stretch | A standardized mechanism for product inventory management such as creation, partial or full update and retrieval of the representation of a product in the inventory. It also allows the notification of events related to the product lifecycle | L: [email protected] M: [email protected] | |||||
| 6.03.6 | Service Inventory Management | TMF638 - stretch | Provide a consistent/standardized mechanism to query and manipulate the Service inventory | L: [email protected] C:[email protected]orange.com M: [email protected] | |||||
| 6.03.7 | Service Ordering Management | TMF641 - stretch | The REST API for Service Order Management provides a standardized mechanism for placing a service order with all of the necessary order parameters. It allows users to create, update & retrieve Service Orders and manages related notifications. | L: [email protected] M: [email protected] | |||||
| 6.03.8 | Privacy Management | TMF644 - stretch | The Privacy Management API provides standardized mechanism for privacy profile types, privacy profiles and privacy agreements such as creation, update, retrieval, deletion and notification of events. | L: Orange? | |||||
| 6.03.9 | Service Qualification | TMF645 - stretch | Service Qualification API is one of the Pre-Ordering Management APIs. Service Qualification API goal is to provide service availability at Customer location. | L: Ludovic Robert L: Taka C: [email protected] M: [email protected] | |||||
| 6.03.10 | Appointment | TMF646 - stretch | The Appointment API is one of the Pre-Ordering Management APIs. The appointment API provides a standardized mechanism to book an appointment with all the necessary appointment characteristics. First, the API consists in searching free slots based on parameters, as for example a party. Then, the appointment is created. The appointment has characteristics such as nature of appointment, place of appointment. | L: [email protected], M: [email protected] | |||||
| 6.03.11 | Performance Management Thresholding | TMF649 - stretch | This covers the Threshold aspects of Performance Management, also named Performance Threshold Management or PM Threshold. Provides a standardized mechanism for performance management such as creation, partial or full update and retrieval of the resources involved in performance management (Measurement Production Job, Measurement Collection Job, and Ad hoc Collection). It allows also notification of events related to performance | L: [email protected], C: [email protected], C: [email protected] | |||||
| 6.03.12 | Service Test Management | TMF653 - stretch | Placing a service test with all of the necessary test parameters. A service test is a procedure intended to check the quality, performance, or reliability of a service. | L: [email protected], C: [email protected] | |||||
| 6.03.13 | Prepay Balance Management | TMF654 - stretch | Prepay API manages the balance, recharge (top-up) and transfer resources | L: [email protected] M: [email protected] | |||||
| 6.03.14 | Service Quality Management | TMF657 - stretch | Defines a standard interface designed to simplify the integration task of an SQM application with different partners and respective Digital Operations Centers. | L: [email protected], C: [email protected] | |||||
| 6.03.15 | Shopping Cart | TMF663 - stretch | Standardized mechanism for the management of shopping carts. Including creation, update, retrieval, deletion and notification of event. Shopping Cart entity is used for the temporarily selection and reservation of product offerings in e-commerce and retail purchase. Shopping cart supports purchase of both tangible and intangible goods and service (e.g. handset, telecom network service). The charge includes the one-off fee such as the fee for handset and the recurring fee such as the fee of a network service. Shopping Cart contains list of cart items, a reference to party or party role (e.g. customer) or contact medium in case of unknown customer, In addition the calculated total items price including promotions. | L: [email protected], C: Huawei C: [email protected] C: Orange M: [email protected] | |||||
| 6.03.16 | Digital Service Management API | TMF665 - stretch | Identifies all the relevant resources and document also addresses their lifecycle. This is not an exhaustive list and document in its final form will address in detail the specification as per DSRA, DPRA, ZOOM and other relevant initiatives at TMforum. | L: [email protected], C: [email protected], C: [email protected] | |||||
| 6.03.17 | Partnership Type Management | TMF668 - stretch | Standardized mechanisms for creating partnership types. It is one of the APIs involved in an onboarding process. Identifies a type of a partnership between parties, including the list of role types that are permitted (i.e Buyer, Seller, Developper). Role types may refer to agreement specifications to be signed by parties playing the role. The API allows the retrieval, creation, update and deletion of partnership type and its owned sub-resources. | L: Mariano M: [email protected] | |||||
| 6.03.18 | Party Role Management | TMF669 - stretch | A standardized mechanism for general party roles and includes operations such as creation, update, retrieval, deletion and notification of events. Notice that for the management of customers there is a specific Customer Management API. Party Role management API manages the following data resources: PartyRole | L: [email protected], M: [email protected] | |||||
| 6.03.19 | Promotion | TMF671 - stretch | Used to provide the additional discount, voucher, bonus or gift to the customer who meets the pre-defined criteria. Using promotion, the enterprise is able to attract the users and encourage more consumption, especially continuous purchases. Normally Promotion is not regarded as one type of product or product offering. It is often applied when the customer buys the product offerings with the price or amount surpassing the certain limit | L: [email protected] | |||||
| 6.03.20 | User Roles & Permissions | TMF672 - stretch | A user role is defined as the entity that defines a set of privileges covering various functions and/or manageable assets. When a user is assigned a given role then it is actually allocated all the privileges defined for that roletype and the corresponding permissions are created for that user | L: [email protected], C: Huawei | |||||
| 6.03.21 | Payment Management | TMF676 - stretch | This API allows the following operations. Notify of a performed payment, retrieve a list of payments filtered by a given criteria, retrieve a single performed payment, notify of a performed refund, retrieve a list of refunds filtered by a given criteria and retrieve a single performed refund. | L: [email protected] | |||||
| 6.03.22 | User Interaction | TMF683 - stretch | A User Interaction captures information about past interactions in order to re-use it in future ones. This allows agents to serve users better by knowing the steps they went through. It also allows customers to see better the actions they have performed and how they interacted with us. | L: [email protected] | |||||
| 6.03.23 | Shipping Tracking | TMF684 - stretch | Shipment Tracking captures information about the current status of the shipment, the past checkpoints and the estimated arrival date. Via this API, tracking information can be retrieved by providing an order Id or the shipping company’s tracking id. | L: [email protected] | |||||
| 6.03.24 | Event management | TMFnnn - stretch | Event is any of the action triggered by the human or the system which requires the notification to the other system. | L: [email protected] | |||||
| 6.03.25 | Experience Management | TMFnnn - stretch | Experience is the data and their impact which reflect the feeling of the user of the system. Based on the experience, the user can give judgment to the system about its usability | L: Ericsson? C: Proximus | |||||
| 6.03.26 | Federated Identity | TMFnnn - stretch | Identity management is about the management of principals of any kind (persons, objects, …) and their access to resources in an open environment which can span across different enterprise boundaries. It relies on authentication, authorization and consent mechanisms to protect privacy with a simple and easy user experience. Different parties can provide identity services (operators, social networks, GSMA, …). | L: [email protected], C: Ericsson? | |||||
| 6.03.27 | Resource Pool Management | TMFnnn - stretch | RPM API offers the available capacity confirmation of Services / Resources and pre-reservation of them BEFORE the order | L: [email protected], C: [email protected] | |||||
| DSM | See 665 above | Keep here or seperate workstream? |
6.04: Open API components
Workstream Leader: Pierre Gauthier, Stephen Harrop
How do we build up TM Forum Open API suites, based on use case and requirements analysis, to support specific industry challenges?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.04.1 | What is a C & P for a conformance suite? | TRnnn - API Component Suite concepts & principals TRnnn - template | TRnnn: what is an API component suite? TRnnn: How should others document their component suites in an efficient & repeatable way? | Pierre Gauthier | |||||
| 6.04.2 | TRnnn: NaaS component suite | Network as a Service (fka End-to-End NFV Management APIs) | Johanne Mayer | ||||||
| 6.04.3 | TRnnn: IoT | IoT component suite | Axel Pieuchot | ||||||
| 6.04.4 | TRnnn: Self Care | Self Care Application component suite | |||||||
| 6.04.5 | TRnnn: MEF product suite | Ludovic Robert | |||||||
| 6.04.6 | TRnnn: ONAP product suite | Ludovic Robert |
6.05: API/SID mapping Task Force
Workstream Leader: Cecile Ludwichowski, Michel Besson
How do we ensure that the TM Forum Open APIs, developed by a wide collaboration community and crowd sourced, have a consistent information model and data model view - with each other and with SID?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.05.1 | White Paper: New overall document - the generalities of how mapped - eg 15 pages for ALL the APIs. | ||||||||
| 6.05.2 | API / SID mappings in progress | TMF663A, TMF653A, TMF633A, TMF638A, TMF673A, TMF658A, TMF662A, TMF645A, TMF621A, TMF639A
| TMF663 - Shopping Cart: Jonathan Goldberg (Amdocs), TMF653 – Service Test: Hongxia (Helen) Hao (Huawei), TMF633 - Service Catalog Management 17.5 : Cécile Ludwichowski (Orange) & Michel Besson (TMF), TMF638 – Service Inventory Management: Cécile Ludwichowski (Orange) & Michel Besson (TMF), TMF673 – Geographic Address Management - Luis Velarde (Telefonica), TMF658 - Loyalty: Narayanan Krishnamurthy (Infosys), TMF662 - Entity Catalog: Kamal Maghsoudlou (Ericsson), TMF645 - Service Qualification: Atif Syed Husain (Infosys), TMF621 – Trouble Ticket: Yaniv Gigi (Amdocs) or maybe another colleague (Jacob Avraham), TMF639 - Resource Inventory : Jonathan Goldberg (Amdocs) | ||||||
| 6.05.3 | API / SID assigned mappings | TMF640A, TMF654A, TMF632A, TMF666A, TMF668A, TMF669A, TMF620A, TMF641A, TMF674A, TMF675A, TMF655A, TMF680A, TMF681A, TMF657A, TMF671A | TMF640 - Service / Resource configuration & Activation: Atif Syed Husain (Infosys), TMF654 – Prepaid Balance: Jonathan Goldberg (Amdocs), TMF632 – Party: Calogero Cascio (Accenture), TMF666 - Account Management: Cécile Ludwichowski (Orange), TMF668 - Partnership type (previously named Onboarding TMF650): Michel Besson (TMForum), TMF669 - Party Role: Cécile Ludwichowski (Orange), TMF620 – Product Catalog Management Kamal Maghsoudlou (Ericsson), TMF641 - Service Ordering 16.5: Cécile Ludwichowski (Orange) & Michel Besson (TMF), TMF674 – Geographic Site - Luis Velarde (Telefonica), TMF675 – Geographic Location - Luis Velarde (Telefonica), TMF655 – Change - Hongxia (Helen) Hao (Huawei), TMF680 – Recommendation (R 17.5) - Hongxia (Helen) Hao (Huawei), TMF681 – Communication (R 17.5) - Hongxia (Helen) Hao (Huawei), TMF657 – Service Quality - Hongxia (Helen) Hao (Huawei), TMF671 – Promotion - Hongxia (Helen) Hao (Huawei) | ||||||
| 6.05.4 | API / SID mappings as yet unassigned | TMF651A, TMF667A, TMF652A, TMF623A | TMF651 – Agreement, TMF667 – Document, TMF652 – Resource Order Management, TMF623 – SLA Management | ||||||
| 6.05.5 | Mappings that require revision | TMF637A, TMF678A | TMF637 - Product Inventory: Jonathan Goldberg (Amdocs), Based on API 16.5, new release in 17.5. TMF678 – Customer Bill Management: Cécile Ludwichowski (Orange), Based on SID 17.0, new SID 17.5 changes mapping related to Account |
6.06: Finalize Part Completed APIs (API Spec + CP + API/SID mapping)
Workstream Leader: Pierre Gauthier, Stephen Harrop
How do we ensure that the TM Forum Open APIs, developed by a wide collaboration community, are brought to full implementation; spec, CP, SID mapping, swagger, postman, RI & CTK?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.06.1 | Outstanding items & priority as set by 6.02 - Complete the API table for existing APIs |
6.07: API Tooling and Automation Support
Workstream Leader: Stephen Harrop, Mariano Belaunde
How do we create a low friction and repeatable way for our collaboration community to create consistent and low effort swagger files, RI & CTK?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.07.1 | Update to support DG3.0 |
6.08: SDO Collaborations
Workstream Leader: Pierre Gauthier
How do we collaborate with other SDOs build up TM Forum Open API suites to support specific industry challenges?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.08.1 | MEF support | Finalize Part Completed APIs (CTK) New APIs for MEF support - eg trouble ticket Apache version of MEF API | Ludovic Robert | ||||||
| 6.08.2 | ONAP TMF API Technical Architecture | TRnnn | TR ONAP TMF API Technical Architecture - Technical paper exploring the technical architecture requirements to support an ONAP service enablement | Ludovic Robert | |||||
| 6.08.3 | OSM, … | ||||||||
| 6.08.4 | ETSI, … |
6.09: Catalog Management
Workstream Leader: Jonathan Goldberg
How do I, as service provider or vendor partner utilize enterprise catalogs to enable product offer creation in an open, efficient and easily understood manner?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.09.1 | TMF620 | Product Catalog API: Check if there are JIRA issues left to be processed | Jonathan Goldberg | ||||||
| 6.09.2 | TMF633 | Service Catalog API: Check if there are JIRA issues left to be processed; This API is going to be presented to ONAP. Plus new project under OPEN API Apache terms | Ludovic Robert | ||||||
| 6.09.3 | TMF634 | Resource Catalog API: JIRA Issues Expected (None identified yet) | |||||||
| 6.09.4 | tbd | Product Catalog API Reference Implementation: to be Completed | |||||||
| 6.09.5 | tbd | GB978 Interface to Interface Catalog Interface: R18.0 work not yet identified: | |||||||
| 6.09.6 | TMF662 | Entity to Entity Catalog API: R18.0 work not yet identified: |
6.10: Crowd-Sourced APIs
Workstream Leader: Stephen Harrop, Andreas Polz
How do we ensure that the TM Forum Open APIs, developed by a crowd sourced community, are brought to full implementation; spec, CP, SID mapping, swagger, RI & CTK?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.10.1 | Clear plans & delivery of all the crowd source phases & review of each step & product ownership to execute on full deliverable set |
6.11: Open MicroServices and APIs
Workstream Leader: Pierre Gauthier
How do we create industry leading and technologically leading APIs that have design patterns that are optimised for the cloud based ecosystem?
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.11.1 | Technical recommendation on how to best use Open APIs within the context of a microservices architecture - how to use the APIs to front the microservices architecture | ||||||||
6.11.2 | Open MicroServices | TRnnn | FAQ , Templates, Specifications and Cloud Platform based implementations on proposed MicroService and API architectures - First deliverable is a TR prior to Lisbon Pierre Gauthier, Nicoleta Stoica |
|
|
|
|
|
6.12: Event Streaming & Messaging
Workstream Leader: Pierre Gauthier
| Ref # | Deliverable short name | Deliverable type/number | Description | Audience | Intended use | Plan for 1st 90 days | Plan for end of cycle | Sponsor / consumer support | Notes |
| 6.12.1 | Event Streaming & Messaging |
7. Member Validation and Feedback Approach
Deliverables require validation and feedback. If the development team has a broad range of Members and Service Providers, validation may be within the team, however if the range of Members and Service Providers is weak, after Team Approval, deliverables must be validated beyond the team. Teams must state their Member & Validation approach here:
Validation Activity Approach | Spec Jams |
Validation Activity Description | Face-to-face meetings to resolve & clarify requirements and implementation design, as appropriate to the audience |
Dependencies |
|
Comments |
8. Project Tooling
Indicate the tooling required for project success.
Product | Key Functions | Needed for Project? |
Confluence Space | Document creation and publishing | Provided by default |
JIRA Space | Contribution and feedback management | Provided by default |
GitHub | Code repository (if applicable) | YES |
Other | Public website API Portal | YES |
9. Liaison Relationships
Please indicate if this project has or plans to have a relationship with other External Standards Organizations (SDOs).
Name of Organization | Is this a New or Existing relationship? | Linkages and/or Scope of work | Contact person | Comments |
|---|---|---|---|---|
MEF | existing | Sharing API standards |
|
|
| FIWARE | existing | Sharing API standards | ||
| Eclipse/Papyrus | existing | use of Tooling | ||
| Open NFV | Tentative |
10. Charter History
11. Role Definition & Responsibilities
12. Legal Notice
Copyright © TM Forum 2017. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to TM FORUM, except as needed for the purpose of developing any document or deliverable produced by a TM FORUM Collaboration Project Team (in which case the rules applicable to copyrights, as set forth in the TM FORUM IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by TM FORUM or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and TM FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Direct inquiries to the TM Forum office:
240 Headquarters Plaza
East Tower – 10th Floor
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org