HE> The current implementation includes the - more academical - HE> possibility that a client generates an object path by itself, HE> which is definitely a controversial and not recommended HE> approach. This is not problematic as long as the client takes care HE> of all key properties. Only the case that key properties are not HE> handed over by the client breaks interoperability. Well, if all of the other key properties are unrelated to the output, I don't see how it matters. In most cases, we have one true key and the rest are all identical. If the client fashioned an object path with two conflicting keys, then it would make sense to reject the request, and the current implementation would do so correctly. For the sake of human-driven manual testing, it seems reasonable to me to ensure that the client provided enough keys to adequately disambiguate the requested instance from any others. However, I can appreciate that this is not the common case and that a normal client should be using only object paths that we have previously generated. HE> The reason why the CIMOMs do not check the key properties (and HE> accept not set key properties ) might be, that no CIM spec does HE> definitely clarify the responsibilities here. So the CIMOM hands HE> it over to the provider. Which makes sense as the provider is the HE> one with the implementation logic for the key generation and HE> always needs a way to identify its real instances out of a given HE> object path. Right, which is why I originally had a list of required properties passed to this function. Because the CIMOM doesn't do its own checking, we have to do it. Since we know the domain, we should be able to be intelligent about which properties will always be identical, and which are really required for disambiguation. That said, your fix is small and easy, so if you want to write up a formal patch, I'll apply it. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com