Skip to end of metadata
Go to start of metadata




  • Admin
    • Consolidate the dates of next virtual meetings
  • Review/Consolidation of TR-548 RIA-Streaming
  • Review of performed modifications for alignment (492 and 493 now merged)
  • Continue discussion on yang2oas tool - make exact point of the issues 
  • Build agenda for next virtual meetings

Discussion items

10 minsAdministrative

 TAPI Call: 3 hours

  • Review/Consolidation of TR-548 RIA-Streaming
  • Continue discussion on yang2oas tool
  • Continue to build agenda for next virtual meetings and update the TAPI Roadmap

Arturo Mayoral proposed to organize a virtual meeting, given the number and complexity of the items to be analyzed. Agreed to anticipate of one hour.

Tentatively proposed two sessions of 3 days / 6 hours (e.g. 1pm - 7pm CET)

  • Session 1:  
  • Session 2:  
5 mins

Review/Consolidation of TR-548 RIA-Streaming

Nigel Davis draft would be ready but needs some work to correctly highlight the deltas. Presentation is postponed to next week - also considering that attendance today is still limited due to ITU-T meeting.

5 mins

Review of performed modifications for alignment (492 and 493 now merged)

Karthik Sethuraman confirms the correctness of yang modules, but for the enumeration EQUIPMENT_OBJECT_TYPE (tapi-equipment.yang) in 2.1 branch. It has been generated as an identity and extends the base tapi-common:OBJECT_TYPE which is not present in 2.1 branch.

Andrea Mazzini corrected, will commit.

Karthik Sethuraman and Nigel Davis recall that there is an issue regarding the translation of UML [n..*], with n>0, to YANG "min elements n".

Karthik Sethuraman is using Visual Studio Code, which provides a well maintained yang editor plugin, useful to check consistency of modules. Note that Papyrus is no longer maintaining its yang editor.

70 mins

Continue discussion on yang2oas tool - make exact point of the issues

Karthik Sethuraman notes that besides UML and yang, it is also necessary to review/validate the OAS/yaml modules when delivering TAPI. Consider that now there are more Resconf experts who can highlight deviations from compliance. In the room nobody knows about other open source tools converting yang to OAS.

Karthik Sethuraman There is an issue regarding node-edge-point and owned-node-edge-point, some manual editing is necessary.

Considering that ONF/TAPI is the only known user of the tool:

Brief review of the OAS open issues (in red the possible next steps)

  1. OAS Swaager is not RESTCONF #494: agreed that removing OAS from TAPI delivery is not the solution, rather is preferable to amend/enhance the tool as necessary. Arturo Mayoral this is one of the major outputs of OIF Interop.

    • We shall add this comment
  2. JSON Body structure according to RESTCONF standard #37: Arturo Mayoral clarifies that is a well known issue, he is manually editing the yaml modules amending only what necessary to support RIA requirements (about 20 items). This approach is anyway not sustainable. Arturo Mayoral also clarifies that the missing prefix of the "list" is not an issue for json, while is wrong for xml.
    • If ONF/TAPI recommends JSON encoding (*), then the issue can be closed (need to doublecheck)
  3. Use namespaces ONLY when the parent node is in different module (or is the "first" node) - from RFC 8040 3.5.3 #32
  4. Problem with autogeneration of code from the OAS #430: looks like a limitation of go-swagger SDK generator.
    • Issue can be closed
  5. OAS Document Structure #392: Andrea Mazzini shows the script ( used for OAS generation, where the dependencies between YANG modules are specified. Arturo Mayoral this could be a solution for the issue.
  6. Ambiguity in the response schema for the same API across different swagger files #365: agreed that in reality is the model itself which specifies more "paths" to same type of data node.
    • Issue can be closed

(*) Agreed that JSON encoding is the most popular one, while XML no longer, hence it seems appropriate to recommend only JSON for TAPI.

New issue:

  • Some “get all of” listed in TR-547 - Table 3, e.g.
    • /data/tapi-common:context/service-interface-point/
    • /tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service/
    in the yaml are not present, i.e. there is only the get of single SIP/ConnServ, identified by uuid.
  • Arturo Mayoral explains that GET operations to retrieve multiple elements are allowed if the response encoding is based on JSON, this is the reason why the GET operations to lists elements of the TAPI tree such, /data/tapi-common:context/service-interface-point/ or /tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service/ are allowed in TR-547.
    • In previous versions of TR-547 these "get all of" were not present.
  • In case of XML encoding, a dedicated container is necessary for the multiple replies, while not for JSON.
  • Arturo Mayoral mentions the IETF reference
    • If any content is returned to the client, then the server MUST send a returned for XML encoding.  If multiple elements are sent in a JSON message-body, then they MUST be sent as a JSON array.

  • Agreed that if ONF/TAPI recommends JSON encoding, then the issue of the tool must be solved.
30 mins

Build agenda for next virtual meetings

Arturo Mayoral presents otcc2020.AMLL.001.Open Issues TAPI v2.1.4.docx