Task 1 Scope Controller LND Purpose Provide further

Task 1 Scope – Controller (L=ND) • Purpose – Provide further examples of NE deconstruction and other controller forms • Specifically – PC, CD and Controller/View assemblies • Includes – Examples of use of 1. 3 model and modifications to model as necessary (including any overhanging comments from 1. 3) • Excludes – Convergence of C&SC and Controller • External Dependencies – None identified • Assumptions • Risks – No identified risks. The 1. 3 model is in reasonable shape to take this next step Revision #. # © 2017 Open Networking Foundation 1

Task 2 a Scope – Processing Construct (L=Chris. H) • • Purpose – look at aligning PC with TOSCA node concept Specifically – produce a presentation pack and present to TOSCA at our Nov face to face Includes – updating the PC document and model as required Excludes – External Dependencies – dependent on TOSCA availability and interest Assumptions – That TOSCA is interested in aligning with us Risks – TOSCA may not be available in Santa Clara to meet in person Revision #. # © 2017 Open Networking Foundation 2

Task 2 b Scope – Processing Construct (L=Chris. H) • • Purpose –re-look at Control. Component vs Processing. Construct Specifically – recommend how to align PC and CC Includes – updating the PC document and model as required Excludes – updating the control document or model External Dependencies – solution for Control. Component will depend on Task 13 Assumptions – that task 13 completes in time Risks – task 13 is late and we can’t make these changes Revision #. # © 2017 Open Networking Foundation 3

Task 3 Scope – Spec Model (L=ND) • Purpose – Further develop spec model and especially scheme spec • Specifically – Determine whether all specs are really scheme specs • Includes – Refactoring all existing spec models and producing examples of use. Taking input from Po. Cs of spec approach • Excludes • External Dependencies – TAPI constraints (not wanting to change model due to implementation). MEF usage of spec. There is a need for Po. C. Work on Model Structure. • Assumptions – • Risks – Complexity of problem space and volume of work. Alternative approaches. Revision #. # © 2017 Open Networking Foundation 4

Task 4 Scope – Software (L=Chris. H) • Purpose – add Software representation to the ONF CIM • Specifically – software inventory and running software. TMF TR-225 will be a good starting point + SYSAPPL-MIB (IETF RFC 2287) • Includes – Software process / thread. File system, directory and file model. Relationships to software provided functions (PC, FC etc. ) which should be consistent with (running) hardware provided functions and the hardware the software is running on • Excludes – Storage model (disk, LUN, partition, extent). • External Dependencies - None • Assumptions - None • Risks – Scope could get out of control. Revision #. # © 2017 Open Networking Foundation 5

Task 7 Scope – Layer Examples (L=Xiang Y) • Purpose – Show the CIM structure supports various Layer Examples • Specifically – More examples of layers (as called for by TAPI etc), * L 1/2 Circuit; * L 2/3 (inc LAG) Packet; * (including some key multilayer cases) • Includes – Updating TR-512. A. 5, & A. 6 as needed • Excludes – TR-512. A. 4 * L 0 (media (photonic and wireless)) Analogue can be expanded after 10/2017 and is dependent upon the Analogue and Media model (Layer 0) in G. media -mgmt in ITU-T SG 15. • External Dependencies – • Assumptions – TR-512. A. 5, & A. 6 to be published in time in 10/2017 • Risks – Getting the right focus to the examples to maximise the insight from minimum number of cases. Revision #. # © 2017 Open Networking Foundation 6

Task 8 Scope – Equipment Enhancement (L=Kam. L) • Purpose – enhance the equipment model (as called for by TAPI) • Specifically – (1) Spec model for equipment capability; (2) Defining the properties of the equipment; (3) Relationship to the software that is running on the equipment • Includes – updating the Equipment document and model as required • Excludes – • External Dependencies – This work may impact the other models (Equipment Software Function) • Assumptions – for v 1. 5 • Risks – None Revision #. # © 2017 Open Networking Foundation 7

Task 10 Scope – Operation Patterns (L=ND) • Purpose - Model patterns to support API operations patterns including intent (with MEF intent (ex-Boulder)), TOSCA , policy • Specifically – Create a model grammar to cover all API operation forms including command-response and request/query • Includes • Excludes – Tooling to intertwine operations model pattern with information model to form specific interface model that then drives schema generation • External Dependencies – TOSCA engagement • Assumptions – Convergence of TAPI with intent and TOSCA is a target • Risks – Collides with MEF work. Sophistication/complexity of work. Another activity exists elsewhere covering some or all of this. Revision #. # © 2017 Open Networking Foundation 8

Task 11 Scope – Views (L=ND) • Purpose - View abstractions and virtualisation • Specifically – Further developing the relationships in the model that support view abstraction. Providing examples of use of these relationships. Relating the view abstraction model to the Architecture. Creating a clear definition of the meaning of “xyzview”. • Includes – Relationship to component-system pattern and formation of a view pattern • Excludes – Tooling/code that realizes the view abstraction • External Dependencies – Depends on development of Constraint. Domain. Model restructuring • Assumptions • Risks – Model coupling challenge. Keeping to the scope of the problem. Revision #. # © 2017 Open Networking Foundation 9

Task 12 Scope – Entity Lifecycle (L=MB) • Purpose – Extend current model to include split/merge • Specifically – Consider the merge and split of entities: Add further description on the use of the Entity lifecycle states as requested by TAPI • Includes – Extensions to the lifecycle model • Excludes – Consideration of the temporal model • External Dependencies - None • Assumptions - None • Risks – Potential complexity of some merge cases (where the entities to be merged are in different lifecycle states) Revision #. # © 2017 Open Networking Foundation 10

Task 13 Scope – Model Structure (L=Chris. H) • Purpose – look at the current ONF CIM structure and produce recommendations and document architectural patterns / guidelines for future work • Specifically – look at improving the model modularity and managing dependencies • Includes – producing an action plan for any recommended model changes • Excludes – actually changing the model • External Dependencies – None, but his work may impact other items. • Assumptions – That the model can be refactored at a later date when these guidelines are approved by the team. • Risks - None known at this stage Revision #. # © 2017 Open Networking Foundation 11

Task 14 Scope – Topology (L=ND) • Purpose – Enhance topology model and aim to “harmonize” TEAS/ONF work • Specifically - IETF TEAS comparison. Fix Forwarding. Entity _PAC model (should be decoration/spec) • Includes – Generation of a TEAS/ONF positioning paper. Using the spec mechanism and decoration to replace the _PAC approach. Coverage of further outstanding actions • Excludes • External Dependencies – Specification model • Assumptions • Risks - Revision #. # © 2017 Open Networking Foundation 12

Task 15 Scope – Model Rationale (L=Kam. L) • Purpose – enhance CIM rationale description • Specifically – (1) Business need; (2) Benefit of CIM; (3) Model evolution • Includes – how the current model satisfies the need; next steps in the context of evolution and vision • Excludes – • External Dependencies – None • Assumptions – for v 1. 4 (? ) or v 1. 5 • Risks – None Revision #. # © 2017 Open Networking Foundation 13

Task 16 Scope – P&R Methodology (L=ND) • Purpose - Prune&Refactoring methodology and tooling enhancements • Specifically – Enhance the P&R capability and apply to model federation • Includes – Description of the P&R methodology. P&R tooling. Scheme spec generation. Federation of models trial. • Excludes • External Dependencies – Scheme spec work • Assumptions • Risks – Complexity and unboundedness Revision #. # © 2017 Open Networking Foundation 14

Task 17 Scope – UML Modelling Guidelines (L=BZ) • Purpose - Develop UML guidelines for a harmonized modeling infrastructure • Specifically - Assure consistent information models by selecting a subset of the artifacts defined in the UML specification. • Includes – UML artefact descriptions; UML profile definitions; recommended modelling patterns; common data types • Excludes – Is not a UML tutorial • External Dependencies – Usage of UML artifacts and modelling patterns in other SDOs • Assumptions – Although the guidelines are written tool independent, it is assumed that the Papyrus tool is used • Risks – Model designers use other modelling patterns; a UML tool might not support all recommended artefacts or patterns Revision #. # © 2017 Open Networking Foundation 15

Task 18 Scope – Papyrus Guidelines (L=BZ) • Purpose – Enable UML model designers to use the open source UML tool Papyrus • Specifically – Assure a consistent UML tool usage among different model designers • Includes – Getting Papyrus running; Git. Hub usage; Papyrus usage; class diagram style sheets; model reporting (data dictionary) using the Gendoc tool • Excludes - Is not a Papyrus tutorial • External Dependencies – Papyrus release roadmap; support of UML artefacts; import/export features; support of UML diagram types; support of the Papyrus community • Assumptions – Papyrus is used in many SDOs; Papyrus will be continuously evolved • Risks – Required features may not / no longer be supported; stability of the tool Revision #. # © 2017 Open Networking Foundation 16

Task 19 Scope – UML to YANG Mapping Guidelines (L=BZ) • Purpose - Defines guidelines for mapping a protocol-neutral UML information model into a YANG data schema • Specifically - Provides the requirements for the UML to YANG mapping tool • Includes - Mapping rules for UML artefacts and their properties; mapping rules for modelling patterns; mapping rules for common data types; YANG module header entries • Excludes - Reverse mapping from YANG to UML • External Dependencies - YANG specification; YANG best practices; YANG module design style of other SDOs • Assumptions - The UML model has been designed using the UML Modelling Guidelines • Risks - Model designers use patterns not defined in the UML Modelling Guidelines; change of features in the YANG specification; YANG module design style of other SDOs Revision #. # © 2017 Open Networking Foundation 17

Task 99 Scope – (L=) • • Purpose Specifically Includes External Dependencies Assumptions Risks - Revision #. # © 2017 Open Networking Foundation 18