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

More complete examples that show the actual QoSConstraint structures, the deployment of QoSEnablers, the negotiation, and the use of the COPIs would be really helpful in understanding the spec.

Derivation of RequestInfo Why isn't ContainerClientRequestInfo simply derived (with no extension) from PortableInterceptor::ClientRequestInfo? This would save a step (calling request_info()) in user code. Why isn't ContainerServerRequestInfo simply derived (with no extension) from PortableInterceptor::ServerRequestInfo? This would save a step (calling request_info()) in user code.

Can anyone explain why the ExtensionComponent only delivers the
ccm_remove method and not all the other methods which the
SessionComponent has?

The operations in the interface StubContainerInterceptor have an out boolean parameter called "con". It corresponds (I think) to the parameter "proceed_call" described in the text and should therefore be renamed accordingly

In section 8.11.4 (deployment), the ComponentInstallation interface is
referenced. It no more part of the current CCM specification and shall be
replaced by elements of D&C spec. NodeManager for the physical
transportation and NodeApplicationManager for the loading of libraries