Skip to end of metadata
Go to start of metadata

 | 2am PST | 5am EST | 10:00 UTC | 10:00 GMT | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |

Web Conference: 


(please feel free to correct and update your names (wink) Thank you very much!!!) 

Discussion items

00:00Chair topic 
no update 



2021-12-22: Martin Skorupski

2021-12-29: canceled

2022-01-05: canceled

2022-01-12: Martin Skorupski


@Alexander Wenk


Input by Prathiba:


  • target for yang  2021-12-15
  • augment LTP for embeddedClock in sync
00:59ltpName @Andreas Lattoch

Please see new created issue for this topic



Centralized alarm list

(alarm definition, capability and notification)

Continue UML Modeling

  • Clarification of alarmTypeId and probableCause based on examples...

Q: Do we need a restriction in AlarmCapabilities for supported severities?

A: ??? No???

Q: Shall their be an alignment between capability and configuration (number of entries in a list)?

A: ??? Yes ???

If yes, how to ensure consistency? (referencing the same keys, one list (NMDA like), ....)

00:00Relation between planning and actual data from the network

Please see the latest version of the proposal:

AI Vendors: Please prepare questions to continue.

  • on the agenda for next Tuesday 
00:35Mediator Instance Manager

Pre- Discussion happened yesterday 

  • info send by Thorsten on Monday 2021-05-177
  • in addition Thorsten will send the "background discussion slide"....

Mediator Instance Manager 

  • What is the protocol? NETCONF or REST or RESTCONF or ...
    • Working Assumption:  not decided
    • SIAE would like to decide based on efforts after analysis. 
    • UML include the "service" - but not the operational and maintenance layer
    • YAML (OpenAPI3) → UML (papyrus) → YANG → 


  • Any questions?
    • no questions


  • please see "App layer on top of the SDN controller" above.


  • Introduction to the topic 
  • functional requirements
  • how to address security constrains and its key management
  • impact on MediatorInstanceManager
    • including logging mechanism
  •  option to reuse code provided by TEF


  • Create Mediator Instance
    • Q: Is device-port missing?
    • A: no - because this is knowledge of the Mediator-Instance
    • (Management) Protocol and protocol version and other protocol configuration parameters : depend on 'device-kind-name'.
    • Further Configuration comes as general configuration with the "LoadFile" (e.g. NETCONF port range, SNMP version, SNMP TRAP port)

    • Q: Release version for in device parameters?
    • A: also here the mediator implementation knows what to do. 

    • Q: device-kind-name: enum vs. string
    • A: type sting → ok but known values must be agreed between vendor and operator OPEN...... to be continued tomorrow.


  • some "security" findings by TEF IT - to be addressed - some repos changed to "private" - access by git invitations - please send github accounts to Thorsten. 


Action items