| Time | Item | Who | Notes |
|---|
| 15 mins | General Administrative & Status | Karthik Sethuraman | - Next TAPI call: Next week
- Jan 29 - MEF Q1, but we will have the call
- Joint ITU-T SG-15 Q14 & IEEE 802.1 CFM YANG/UML & ONF coordination call for G.8052.1
|
| 10 mins | Review: TAPI Work Items and release plan | Karthik Sethuraman | - TAPI SDK release schedule (timefarme based)
- 2.0.0 - 2018 Jan-start
- 2.0.1 - 2018 Feb-mid
- 2.0.2 - 2018 Mar-end
- 2.1 - 2018 July-end
- OTSi Spec Model Updates to include OMS/OTS Media
- ETH Spec Model Updates to include OAM
- ODU Spec Model; Updates to include OTU
- DSR Spec Model
- OAM Model Updates to align with MEF NRM-OAM
- Notification Model Updates
- Equipment/Inventory Model (previously scheduled for 2.2)
- OpenAPI updates for RESTConf compliance
- 2.2
- Timeline - 2019 Mar-end (Q1-end)
- SNAPSHOTS: Weekly starting Jan 2018 (TAGS)
- RC1: 2019 Jan-end (feature freeze)
- RC2: 2019 Feb-end
- RC3: 2019 Mar-mid
- Release: 2019 Mar-end
- Work Items
- Photonic Model updates
- OAM Model Updates
- Profiles & Templates
- OAM Profile - to support Ethernet PM, thresholds
- SLS Profile
- Routing Constraints
- Resilience Constraints
- Node Constraints
- Equipment Inventory
- ETH Model (non-OAM) Updates
- ODU Model Updates
- DSR Model Updates
- YANG conditional augments
- RESTConf/OAS Bugs/Enhancements
- Python-Flask Reference Implementation
- TAPI Requirements Updates (TR-527)
- TAPI Work Items (not release specific - checked means "being worked on")
- TAPI Model Refinement/Enhancement
- OAM model
- Virtual Network model
- Notification model
- Routing Constraints
- Resilience Constraints
- TAPI Documentation/Scenarios/Examples
- Termination Examples
- Multilayer Scenarios
- OAM Scenarios
- Node Constraints
- Technology Spec Model
- ODU/OTU
- OTSi Media
- DSR
- Ethernet
- Wireless
- TAPI Reference Implementation framework
- single layer use case
- multi-layer symmetric use case
- multi-layer asymmetric use case
- Equipment Inventory
- Equipment configuration
- Mgmt of Device Control interfaces
- Mgmt of Synchronization/Timing
- Mgmt of Software/Firmware download
- LTP Specification structure updates/enhancement
|
| 75mins | Equipment Model | Nigel Davis | - Core IM Equipment Model Overview
 - Equipment Spec Model Details
 - Core IM Connector-Pin-Strand Model Overview
 - Relationship between Equipment/Connector & Access Port
|
| 30 mins | Photonic Model | Karthik Sethuraman | - Continued the discussion on modelling of the MediaChannelAssembly (Group) and MediaChannel (Part) entities (NEP, CEP & Connection)
- Option 1: Only model MCAssembly NEP, CEP & Connection
- The individual MC properties are modeled as locally composed ListElements
- Option 2: Only model the MC NEP, CEP & Connection
- The fact that NEPs/CEPs/Connections are part of an MCAssembly is captured via an groupId property such that entities belonging to the same assembly will have the same groupId
- Option 3: Model both MCAssembly & MC NEPs/CEPs/Connections as first class entities (with their own UUIDs) - current TAPI 2.1 approach
- An MCAssembly NEP/CEP/Connection aggregates references (pointers) to the MC NEPs/CEPs/Connections
- In case of an MCAssembly of one MC, explicitly providing MCAssembly NEP/CEP/Connection is optional since the MCAssembly NEP/CEP/Connection currently have no explicitly defined photonic properties (other than aggregation of part-references).
- This can change if we do define some useful photonic properties in MCAssembly NEP/CEP/Connection
|
