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

2. Team Members Leader - Chris Hartley chrhartl@cisco.com Members
Nigel Davis
Malcolm Betts
Augie J

3. IPR Declaration Is there any IPR associated with this presentation NO
NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on Cisco or any other company. The requirements are subject to change in form and numerical value after more study. Cisco specifically reserves the right to add to, amend, or withdraw statements contained herein.
THE INFORMATION HEREIN IS PROVIDED “AS IS,” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

4. TR-512.8_v1.3_OnfCoreIm-Control.docx, fig 3-3
Background
The key question is if ControlComponent is actually needed at all
If it’s just a copy of the PC / CD model, what value is it adding ?
Control component seems oddly absolute (this is a CC, this is not) where a more sensible model would be a relative role (PC controls / is controlled by PC)
ControlSystemView is not really a view but a scope of control