1. 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

2. Task 2a Scope – Processing Construct (L=ChrisH)
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

3. Task 2b Scope – Processing Construct (L=ChrisH)
Purpose –re-look at ControlComponent vs ProcessingConstruct
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 ControlComponent will depend on Task13
Assumptions – that task 13 completes in time
Risks – task 13 is late and we can’t make these changes

4. 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 PoCs 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 PoC. Work on Model Structure.
Assumptions –
Risks – Complexity of problem space and volume of work. Alternative approaches.

5. Task 4 Scope – Software (L=ChrisH)
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.

6. 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), * L1/2 Circuit; * L2/3 (inc LAG) Packet; * (including some key multilayer cases)
Includes – Updating TR-512.A.5, & A.6 as needed
Excludes – TR-512.A.4 * L0 (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 SG15.
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.

7. Task 8 Scope – Equipment Enhancement (L=KamL)
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 v1.5
Risks – None

8. 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.

9. 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 “xyz-view”.
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 ConstraintDomain. Model restructuring
Assumptions -
Risks – Model coupling challenge. Keeping to the scope of the problem.

10. 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)

11. Task 13 Scope – Model Structure (L=ChrisH)
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

12. Task 14 Scope – Topology (L=ND)
Purpose – Enhance topology model and aim to “harmonize” TEAS/ONF work
Specifically - IETF TEAS comparison. Fix ForwardingEntity _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 -

13. Task 15 Scope – Model Rationale (L=KamL)
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 v1.4 (?) or v1.5
Risks – None

14. 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

15. 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

16. 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; GitHub 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

17. 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 

18. Task 99 Scope – (L=) Purpose - Specifically - Includes - Excludes -
External Dependencies -
Assumptions -
Risks -