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

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

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

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

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

TR-532/541 - Overview

TR-532/541 - Structure of *_Pacs

Backup

Interface Description - Netconf