Page History
...
| Time | Item | Who | Notes |
|---|---|---|---|
| 1 | Backward compatibility | The document describing backward compatibility should be updated about description of relations. Analyze Hello message, whether the supported version of YANG model is reported by Netconf Client and Server | |
2 | Proposal 1: Splitting into one UML/YANG per *_Pac | Thorsten Heinze | Currently the TR-532 (document and UML) describes a single YANG, which comprises 6 Pacs (airInterface, airInterfaceDiversity, pureEthernetStructure, hybridMwStructure, tdmContainer, ethernetContainer). The YANG, which is created by TR-541 (Ethernet PHY), also contains pureEthernetStructure and ethernetContainer. It does not make sense that devices, which have microwave radio and Ethernet interfaces, implement two YANGs, which both contain the same (or even worse, different) definitions for pureEthernetStructure and ethernetContainer. This is why it is proposed to split the big UML/YANGs in TR-532 and TR-541 into several smaller UML/YANGs, which contain one *_Pac each. Of course, this change will not take effect on TR-532v1.1. Daniela Spreafico the container ‘pure‘pure-ethernet-structure-current-performance ‘ on the ‘mw‘mw-pure-ethernet-structure-pac’ pac’ contains specific counters like es, ses , cses used only by mw air-interfaces (on 1+1 configuration), not ethernet interfaces. What you have in mind is to export the entire ‘mw‘mw-pure-ethernet-structure-pac’ pac’ with these PM counters or only a generic ‘pure‘pure-ethernet-structure-pac’ pac’ so that the specific ‘mw‘mw-pure-ethernet-structure-pac’ pac’ is retained on microwave model but importing from the generic one? Thorsten Heinze the mw-pure-ethernet-structure-pac and related attributes would not change. It would just be separated into a dedicated UML. |
| 3 | Proposal 2: Referencing a repository that holds UML, YANG, Class Diagram, GenDoc Export and reference implementations | Thorsten Heinze | Currently TR-532 document basically contains and explains the UML. While UML is good for modeling, most implementations are based on YANG. YANG and reference implementations should be part of the TR. It does not make sense printing YANG and code of reference implementations into an appendix of the TR document. This is why it is proposed to store all these items together in a repository and to reference this repository from inside the TR document. Together with Proposal 1: This means that the TR document would contain a list of references that together build the subject of the TR. Hypothetical Option: The same definitions could be referenced in several TR documents with divers subjects. Of course, this change will not affect TR-532v1.1. |
| 3 | Proposal 3: Widening the scope of TR-532 | Thorsten Heinze | Currently TR-532 defines a couple of technology specific extension to the LayerProtocol/LayerTerminationPoint class. It is not enough for configuring the entire wireless transport device. It is also not enough for documenting the wireless transport network. Quality and completeness of the existing definitions already reached a very high level. This is why it is proposed to expand the coverage of the TR-532 on Connections and further Interfaces instead of focusing on updating existing *_Pacs. Describing the Connection between airInterfaces could be a first step. Together with Proposal 1 and 2: This means that the TR document would contain an increasing list of references that together build the subject of the TR. Hypothetical Option: Not all the referenced definitions need necessarily to be elaborated within WTP. Analyzing definitions first and testing interworking of a selection of definitions in the PoC could accelerate provisioning of definitions. Of course, this change will not affect TR-532v1.1. |
...
Overview
Content Tools
Activity