Dynamic configuration of components :
In the Scope section of QoS4CCM specification, the following is mentionned:
"Dynamic configuration and re-configuration is also an essential point of
distributed systems, because in order to adapt an application to a specific
execution environment, one has to be aware that the QoS of the execution
environment evolves during execution. There is a strong need to be able to
make on-the-fly adaptation. That is why it is very important to provide an
architecture, mechanisms, and monitoring concepts that allow dynamic
adaptation of a running application, explicitly by an administrator, but
also automatically. The specification addresses this problem domain in the
context of the CORBA Component Model (CCM) [CCM]."

For example reading/writing component's attributes or installing or
uninstalling non-functional properties is necessary. This issue propose to
address this topic which is not concretly resolved in the current
specification.

To achieve this goal, a small evolution is needed. The existing CCM
specification allows some application specific means like home user defined
operations or 'configurator' setting but such mechanisms don't work without
respectively using home finder or dynamic invocations. The necessity to
develop applications that can dynamically reconfigure components and get
knowledge of component configuration in a generic way, bring us to consider
a new configuration mechanism at runtime to facilitate dynamic adaptation of
running application.
We propose to add configuration ability with access of special
'configurator' implementation using component's home interface. We also
propose to improve StandardConfigurator to get component configuration.This
will allow to configure easily non-functional properties at run-time.

If the component is created dynamically, or configured at runtime, the QoS value needs to be configured either via application specific means or by using configurator. Sections are added to support dynamic adaptation of a running application. This implies the modification of the CCM interface StandardConfigurator to be able to retrieve configuration values. HomeConfiguration interface is also modified to be able to retrieve a configurator.

Service configuration :
The QoS4CCM standard doesn't speak about access of QoS Enabler at container
level. The 'install_service_reference' operation definition allos to
register service reference at container level but doesn't allow the
configuration of the services in a standard way. This would be useful to
have a configuration interface and to invoke it at service installation.

We propose to define a standard QoS Usage's interface to make service
configuration and to improve 'install_service_reference' operation
definition.

We propose to define a standard QoS Usage's interface to make service configuration and to improve 'install_service_reference' operation definition. A new interface QoSUsage to the following interface to make service configuration in standard way. The definition is inserted at end of section 8.11.2

The spec defines the following methods

Cookie
install_service_reference(
in string service_id, in Object objref)
raises (CCMException);
Object
uninstall_service_reference(in Cookie ck)
raises (CCMException);

it is described that the service reference id is unique, so why do we need a cookie at all. It will simplify things for users if we do:

void
install_service_reference(
in string service_id, in Object objref)
raises (CCMException);
Object
uninstall_service_reference(in string service_id)
raises (CCMException);

The specification adds QoSPropertyRegistration as part of the context definition but this interface isn't defined at all in the specification

In the document there are several casing problems, search for CORBA::OCtetSeq, it should be CORBA::OctetSeq