Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.




  • Administrative
    • Beijing F2F meeting Agenda
  • Multi-layer model enhancements (Andrea)
  • TAPI REST-RPC alignment for v2.2-RC2 (Karthik)

Discussion items

20 minsAdministrative
  • Next TAPI Call: Skip the call since MEF Next week (Karthik & Andrea unavailable)
  • TAPI 2.2 Release update

    • Released on April 8, 2019
      • Included items:
        • OAM, Notification Framework updates
          • OAM Job structure refactoring and renaming
          • OAM/Threshold profile
            • Threshold/PM parameter
          • Alarm/TCA linkage to Threshold/PM parameter
        • Equipment inventory model (new feature)
        • Resilience & Routing Constraints fixes/updates
        • Topology Model update
          • Added TopologyAggregatesNEP association
            • The NodeAggregatesNEP association which is supposed to be replaced by above will be kept as deprecated in this release v2.2 and removed in v3.0
            • Done Karthik Sethuraman
        • ETH Technology model updates
          • mainly OAM based on MEF NRM-OAM requirements, review and feedback
        • Photonic model updates
          • mainly power control management & photonic-layer-qualifier labels
        • LLDP defferred to v2.3 or later
      • Includes UML, YANG, Tree files only.
      • OpenAPI & RI will be included in RC2 (not normative)
    • RC2 target May 10th
    • RC3 target May 24th
    • Release target June 7th (2 weeks after RC3)
  • Beijing F2F Agenda plan
  TAPI REST-RPC alignment for v2.2-RC2
  • It was acknowledged that TAPI UML Operations that specify equivalent CRUD operations explicitly are in general redundant and should be removed in Tapi 3.0 since the same can be achieved by updating the code/data-schema generation tools to properly generate the CRUD operations from the class information model and attribute's read/write property.
  • Equivalent RPC parameters and REST/Object attributes should use same label/name.
  • Create/Post operations: 
  • UUID for create/post operations - Since RESTConf requires the client/requestor to provide the key attributes (uuid in case of TAPI) in the create operations for the configurable lists, agreed that all TAPI create/post operations will require the TAPI client to provide an UUID parameter. Will return the created object
  • Delete operations should not return any output (deleted object instance)
  • Update operations - case of strictly composed children classes (e.g. ConnService has strictly composed children CSEPs) - update operation on the parent (ConnService) takes in a list of the child object instances (CSEP list) and the the implementation has to figure out if a child instance (CSEP instance) already exists and if so has to figure out the delta to update the child (CSEP) or absence implies that child instance has to be removed. In some cases, this was deemed confusing and so we provide explicit add/delete/update operations for the strictly composed children (e.g. Create/Delete/Update CSEP). So make this a consistent policy? Agreement: NO
  • Get RPCs - for strictly composed children - present in some case, not present in other cases. Agreed to consistently add (on best-effort basis) any additional get() for strictly composed children (mostly redundant) operations as removing all of these operations would be considered backward-incompatible (major version change).
  • Get All RPCs - for strictly composed children - For now, no additional GetAll RPCs to be added for strictly composed children as these are deemed to be redundant in general.
  • GetIds RPCs - For now, will not implement this in 2.2. In 3.0, we will implement find/search query based API to replace GetAll where it is possible to filter both the number of returned objects and the object attributes/fields.

Action items