...
The need for this is valid and useful. The 'managedBy', relationship may be promoted to the Resource level – to be less proscriptive. Note also that there will be multiple ManagementReference from a single Resource, potentially one for each management domain (e.g. Fault, Configuration, Performance subscription, etc. This also looks like a update to the 'Resource' in the ONAP IM.
Intent and services
Services
The separation of concerns (services and resources) is a principle that should be enshrined in the topology model.
By its nature a service is a simplified abstraction of what is used to realize it. The implementation details typically do not matter to a customer as long as the SLA is met. Bundling the service concepts into a resource model is going to make life more complex. Where there are service specific modeling needs, lets add them to the CFS/RFS Service classes.
Makes sense, aligns with ONAP IM separation to date.
Intent
Intent is a wonderful new buzzword. It is only as good as the interpreter is. Eventually the intent needs to be translated into configuration of endpoints, connectivity and flow domains. Intent is also hierarchical, it will be evolved by layers of interpreters. Of course we need to keep the reference back to the intent for traceability (and possibly in scheduling). This can be achieved by having a simple hierarchical element that is referenced by the 'Resource'. So the participation of any resource in an 'intent' can be traced and interrogated regardless of the interpreter.
...