Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

Discussion items

15 minsAdministrative

 TAPI Call: 3 hours

  • Review/Consolidation of TR-548 RIA-Streaming
  • Continue discussion on yang2oas tool - make exact point of the issues
  • Build agenda for next virtual meetings

Arturo Mayoral proposes to organize a virtual meeting, given the number and complexity of the items to be analyzed.

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

  • Session 1:  
  • Session 2:  
5 mins

Review/Consolidation of TR-548 RIA-Streaming

Nigel Davis reviewing the comments is taking longer than expected. Plan is to have a version ready for review next week.

15 mins

2.1x Alignment to 2.3 / Next Major Release

  •  Review of performed modifications for alignment

Andrea Mazzini provides a summary of performed modifications for alignment:

  • 492 regards 2.1.x and is almost complete (including yang/tree/oas modules), there are some additional small modifications driven by parallel activity on 2.3 / Next Major Release branch
  • 493 regards 2.3 / Next Major Release, production of yang modules ongoing
80 mins

Issue of yang2oas tool not managing the Identity type

Andrea Mazzini explains the issue, the identities defined in yang modules are not managed by yang2oas tool, e.g. layer protocol qualifier is translated only as string, while enums are correctly maintained:

Instances:
        layer-protocol-name:
          description: "none"
          $ref: "#/definitions/tapi.common.LayerProtocolName"
        layer-protocol-qualifier:
          type: "string"
          description: "none"

Definition:

  tapi.common.LayerProtocolName:
    type: "string"
    enum:
    - "ODU"
    - "ETH"
    - "DSR"
    - "PHOTONIC_MEDIA"

Arturo Mayoral considers unfeasible to solve this (and other issues discussed below) by manually editing the generated yaml modules, because of the dimension of files and number of necessary modifications, surely error prone.

Andrea Mazzini shall we roll back to enums? Nigel Davisthere are inherent limitations in enums, e.g. is it possible to "augment" an enum with another enum? We have designed the model following modularity/federation principles.

Andrea Mazzini shows the OAS open issues:

  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.

  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.
  3. Use namespaces ONLY when the parent node is in different module (or is the "first" node) - from RFC 8040 3.5.3 #32: Arturo Mayoral performs a quick check and apparently the issue is solved. See below the action item.
  4. Problem with autogeneration of code from the OAS #430: looks like a limitation of go-swagger SDK generator.
  5. OAS Document Structure #392: Andrea Mazzini shows the script (yang2oas.sh) 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.