kmip-interop-tech — archive

[John Leiseboer]

Apologies for the long email, but I will be unable to attend any of the interop calls this week due to other commitments. If TC-312-12 is discussed, the following may help the group understand the logic behind why QuintessenceLabs has implemented consistent precedence rules for both single-instance and multi-instance attributes rather than opposite precedence ordering illustrated by the TC-312-12 test case. If the group can wait until I am able to dial into a call (should be available next week), then I think I could explain this more easily on the call and clarify any questions arising from interpretation of what I'm trying to say below. To further illustrate the reasons why QuintessenceLabs has implemented Option 2 in preference to Option 1, I offer the following two example use case scenarios: Pre-conditions 1. Server has a Template registered with a set of attributes, one or more of which are single-instance, and one or more of which are multi-instance. 2. Client knows the name of the Template. Context 1. Templates are used to provide a set of default attribute values to clients. 2. Clients may override (some) Template specified attribute values. 3. Sometimes clients may not want to override Template specified attributes - behaviour depends on operational requirements at the time; e.g. the client application might sometimes be performing administration actions, at other times, it might not. 4. When a client doesn't want to override the default attribute values in the Template, it issues a request naming the Template with no additional attribute(s) in the request body. 5. When a client does want to override the default attribute values (noting that index 0 of a multi-instance attribute is the default), it issues a request naming the Template and adds the new default attribute value(s) that it wants the created object to have. Scenario 1 - Client creates key and changes single-instance attribute 1. Client builds a Create request naming the Template, and adds the single-instance attribute to the body of the Create. 2. Client sends request to server. 3. Server creates key with the (default) attributes found in the Template, and replaces the single-instance default value with the value in the request body. 4. Server returns response to client. 5. Client can now access a key with the attribute value it specified rather than the default. Scenario 2 - Client creates key and changes the priority order of multi-instance attribute 1. Client builds a Create request naming the Template, and adds the new higher priority multi-instance attribute to the body of the Create. 2. Client sends the request to server. 3. Server creates key with the (default) attributes found in the Template, and sets the client-specified multi-instance attribute to index 0; i.e. the new default value for this multi-instance attribute. 4. Server returns response to client. 5. Client can now access a key with the attribute instance value it specified as the new default value without needing to set a specific index value. Scenario 1 is currently supported and matches behaviour specified by KMIP by both Options 1 (TC-312-12 strict) and 2 (TC-312-12 QLabs). Scenario 2 is supported by Option 2. If Option 1 is the only allowed behaviour, then in order to satisfy Scenario 2, something similar to the following would be required: Scenario 2b 1. Client builds a Create request naming the Template, and adds no new default attribute values in the body of the Create. 2. Client sends request to server. 3. Server creates key with the (default) attributes found in the Template. 4. Server returns response to client. 5. Client can now access a key with only the default attribute values specified in the Template. 6. Client builds a Delete Attribute request for each multi-value attribute in the Created object. 7. Client sends each of these requests to the server. 8. For each request, the server deletes the attribute instance specified in the request. 9. Server sends response to client. 10. Client can now access a key with the multi-instance attributes of concern no longer present. 11. Client builds an Add Attribute request for the multi-instance attribute value that it wants to be the default (index 0). 12. Client sends the request to the server. 13. The server adds the attribute to the object at index 0. DOES IT REALLY ASSIGN IT index 0? Or does it assign the next index after the one that was used by the last now deleted multi-instance attribute? (I'd have to read and interpret the KMIP spec to work this out.) 13a. If the previous step did not assign attribute index 0, then we can give up now. This process won't work. 13b. Assuming attribute index 0 was assigned, carry on... 14. Server sends response to client. 15. Client builds an Add Attribute request for each of the multi-value attributes that were originally assigned to the Created object by the Template. 15a. How does the client know what the values and order are for these attributes? Maybe between steps 5 and 6 above, the client needs to Get the object and remember the attribute values and order. But wait, a Get operation has side effects - at the very least the Fresh attribute would be set to False. 15b. Okay, so let's assume that the client and server aren't concerned by the side effects of the Get operation, and carry on... 16. Client sends each of these requests to the server. 17. For each request, the server adds a new multi-instance attribute value to the object. Will the first of these be assigned index 1? Similar issue here as step 13. See comments at 13a and 13b. 18. Server sends response to client 19. Client can now access a key with the attribute instance value it specified as the new default value without needing to set a specific index value - which is what we set out to do. Comments Scenario 1 and 2 are consistent with each other, and could probably even be implemented in the client with exactly the same code - no different code paths required for single-instance vs. multi-instance attributes. Scenario 2a is a complicated beast. Some of the request messages could be batched to save bandwidth and latency, but definitely not all of them. Scenario 2a assumes multi-instance attribute index re-use consistent with supporting the use case; i.e. if attributes[0]...[n] are deleted, and new attributes are added to replace the deleted ones, the new ones will get indexes 0 to n+m, in the same order as the original attribute values. Scenario 2a introduces side effects. Fresh set to False is one example. There are probably others (e.g. timestamps), but one is enough to illustrate the problem. Option 2 is a valuable interpretation of the KMIP standard. Customers will see how simple and consistent it is to use KMIP to perform this use case. Option 1 reinforces the idea in some customers' minds that KMIP is a poorly defined standard not suited, or not quite ready, for a lot of important real world use cases. Option 1 - if voted to be the only conformant behaviour - will drive and reinforce non-conformant server implementations. This is something that I would not like to see happen to KMIP. The use case for Scenario 2 is real, and the Option 2 behaviour is a very valuable one to simplify the development, and maintenance of client code performing the use case. The more this issue is discussed, the more I feel that Option 2 is more consistent with the "KMIP model". Attributes in the Create body have precedence over the same attributes in the Template - regardless of whether they are single-instance, or multi-instance. Even if I could be convinced that Option 1 is more consistent with the mythical "KMIP model", the advantages of Scenario 2 above should be enough to at the very least support my request that Option 2 behaviour be permitted in addition to Option 1 in the TC-312-12 test case. John >