1. Pages
2. …
3. Open Transport Configuration and Control Home
4. TAPI
5. TAPI Call-in Details and Notes
6. 2020-11-17 TAPI Meeting Notes

Page History

Review the minutes of 2020Q3 TAPI Virtual Meeting Agenda and Notes Oct. 19/20/21 and Nov. 09/10/11

• TAPI OAS
  
  • Agreed that the depth/fields usage avoids the issue YANG to OAS tool does not generate GET with potentially multiple replies (#497)
    • Nevertheless the generated OAS is not Restconf compliant.
  • Arturo Mayoral considers the depth/fields solution satisfactory concerning documentation, but still not ideal concerning implementation.
  • Arturo Mayoral reminds that the fields filtering does not reduce the number of replied objects/containers, rather selects which of the attributes are reported.
  • Arturo Mayoral indicates that the generated .YAML modules correctly include the whole tree, filtering is to be considered on top of it.
    •  Arturo Mayoralwill update the RIA, adding to the "Table 3: Minimum subset required of TAPI RESTCONF Data API" the required depth/fields filterings.
      • Note that the information about depth and fields is already present in the RIA workflow diagrams, see example below:

• Karthik Sethuraman asks whether we intend to publish the TAPI OAS as normative.
  • After some discussion, considering that the yang2oas tool is still not producing a fully Restconf compliant OAS and to facilitate implementers work (less necessary to read the documentation), it is agreed to split the delivered OAS into two parts:
    1. Normative OAS, the subset of generated OAS which is in the scope of the TR-547 RIA,
    2. Non normative OAS, the whole generated OAS, which could be anyway useful as reference for implementations not following RIA.
       •  Arturo Mayoraland Karthik Sethuraman will work together on the (Python) script to get the normative subset of OAS.
         
• Confirmed that the two currently open issues do not allow the generation of fully Restconf compliant OAS:
  
  1. YANG to OAS tool does not generate GET with potentially multiple replies (#497)
  2. Use namespaces ONLY when the parent node is in different module (or is the "first" node) - from RFC 8040 3.5.3 (#32)
     •  Arturo Mayoralwill evaluate a possible solution to issue #32 above.
       
• With reference to Connectivity Service lifecycle (see Virtual Meeting Notes, Tue 20, P2), agreed to rephrase the requirement, below a proposal:
  • The ConnectivityService (CS) provisioning can cause the creation of Top Connections at the server layer(s), aka top-down scenario. A ConnectivityService must be created per each server Top Connection, to allow the editing of all automatically provisioned network layers.
• All other items of last Virtual Meeting were quickly reviewed, output being the todo list below.

The plan