1. Ethernet PHY Information Model Clarification at OT IM
26st of September 2017
Thorsten Heinze

2. Interface Description
Information Models not sufficient => Interface Descriptions required
Technical Recommendation must contain more prescriptions than just information model
General Targets
Technology specific Experts at Operators must be able to understand the technology specific capabilities of the interface for live network use case definition and application specification
Mediator/Device Developers must be able to implement the interface independently from any further support or guidance aside the Technical Recommendation provided by ONF
Application Developers depend on an unambiguous behavior of the interface, which must be totally independent from the device model or manufacturer

3. Interface Description
Needs of the technology specific Experts at Operators
Current combination of UML and MS Word is good (YANG would not suffice)
Additional explanation required for more complex, but end-user relevant elements
Transparent modeling helps (applies for technology specific extensions)
Structuring attributes in categories that somehow relate to the experts view on the technology helps understanding
Grouping attributes according to Capability, Configuration … prevents misinterpretations
Very generic modeling is maybe covering every imaginable case, but cannot be understood by technology specific experts, who are looking at some model for the first time in their life
Meaningful commenting the attributes is a must

4. Interface Description
Needs of the Mediator/Device Developers
Because translating UML to YANG is ambiguous, YANG must be part of interface description
Experience from PoC and Trial: Mediator/Device developers have problems understanding elements involving the Core IM Additional Information must either be contained or referenced in the technology specific Technical Recommendation
Further details of the implementation to be ruled (currently level is already very good), e.g.
Attribute individual length of String data type
Character set to be supported
Mediators will be a permanent solution for old equipment Model shall allow the mediator to inform about deviations of the equipment from the model, e.g.
Model prescribes String for network element name, but equipment can store just integer

5. Interface Description
Needs of the Application Developers
Interface behavior must be vendor independent also for border cases, e.g.
Configuration of a parameter, which is not supported by the device
Error message, or not?
New value to be answered on future configuration GET requests? …
Partly executed bulk SET requests
Roll-back of successful parts?
Order of execution of elements in bulk SET request must be defined
Insufficient prescriptions in RFC 6241 require specification E.g. can’t request for roll-back of successful parts of bulk SET requests, if NETCONF protocol implementation does not support Candidate Configuration Capability

6. TR-532/541 - Overview

7. TR-532/541 - Structure of *_Pacs

8. Backup

9. Interface Description - Netconf