| From | Sent On | Attachments |
|---|---|---|
| kyel...@us.ibm.com | Feb 18, 2011 6:55 am | |
| Pochuev,Denis | May 16, 2011 10:53 am | |
| Krishna Yellepeddy | May 18, 2011 11:20 am | |
| John Leiseboer | Oct 20, 2011 9:59 pm | |
| robe...@rsa.com | Oct 27, 2011 1:03 am |
| Subject: | RE: [kmip] Groups - Group as a managed object (KMIP-GroupProposal-02182011.ppt) uploaded | |
|---|---|---|
| From: | Krishna Yellepeddy (kyel...@us.ibm.com) | |
| Date: | May 18, 2011 11:20:41 am | |
| List: | org.oasis-open.lists.kmip | |
Denis,
Thanks for reviewing the proposal. Responses below to your questions.
Regards, Krishna Lead Architect, Tivoli Key LifeCycle Manager
From: "Pochuev,Denis" <Deni...@safenet-inc.com> To: Krishna Yellepeddy/Austin/IBM@IBMUS Cc: "'km...@lists.oasis-open.org'" <km...@lists.oasis-open.org> Date: 05/16/2011 12:55 PM Subject: RE: [kmip] Groups - Group as a managed object (KMIP-GroupProposal-02182011.ppt) uploaded
Krishna,
I have a few questions regarding the Group proposal.
1. Can the functionality described in the group proposal be accomplished using existing KMIP means? - Can [Locate "fresh=true"] be done using a Create operation instead? - Can a server-supplied attribute "y-default" be used to designate "default" object in a group?
Answer: A client would need to know details about algorithms, key lengths etc or point to a template with this information when it makes a Create call. With a group set up this is simplified - client specifies [Locate "fresh=true" with object group].
Regarding use of 'y-default', since it is a server side custom attribute each server could interpret it differently. How the server keeps track of the default object in a group is outside the scope of the specification. Object Group member is not being used to keep track of the default object in a group. It is used by the client to specify whether it wants a fresh object or a default object.
2. Can an object registered by a client considered "fresh"? It would be according to the current definition of "fresh". On the other hand it seems that a "fresh" object is one that has not been seen by any client.
Answer: Yes, an object registered by a client can be considered "fresh". Fresh is tied to whether a client did a 'Get' to obtain the object after it has been created or registered.
3. "Replicated" attribute seems to come out of nowhere. I think the attribute itself and the terminology around it (e.g. replication server) would need some definition and broader discussion.
Answer: I agree. I have not added "Replicated" attribute to the specification.
4. There doesn't seem to be an explicit group deletion, and if a group contains many objects, particularly of heterogeneous nature, it would not be straightforward for a client to delete a group.
Answer: An object can be removed from a group by deleting the object group attribute, as long as server policy permits it. A client would need to delete each individual member of a group. Until we have Group as a first class object post KMIP 1.1, we won't have a single operation to delete an entire group.
5. Is it possible to add/modify/delete "fresh" attribute of an object?
Answer: It can be set initially by a client or the server. Subsequently, it is modifiable only by the server.
6. It seems that [Locate "fresh=true"] operation would always have to be batched with a Get request. Otherwise another client can preempt the first one and issue a Get for the object, whose UUID has been returned by the response to the initial [Locate "fresh=true"]. The picture would get even more complicated if the answer to the previous question (5) is "Yes".
Answer: I agree, but this is not an issue unique to the Groups proposal. Any other Locate call with attributes where the attributes can be changed between the Locate and the next operation has the same issue. Even batching does not solve the issue as there is noting in KMIP which requires a batch to be executed as a single atomic transaction.
Thank you for considering my feedback.
Regards, Denis
- - - - - - - - - - - - - - - - Denis Pochuev Principal Software Engineer SafeNet, Inc. Deni...@safenet-inc.com +1 (650) 261-2429
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.





