OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] Groups - Group as a managed object (KMIP-GroupProposal-02182011.ppt) uploaded


Denis,

Thanks for reviewing the proposal.  Responses below to your questions.

Regards,
Krishna
Lead Architect, Tivoli Key LifeCycle Manager



From: "Pochuev,Denis" <Denis.Pochuev@safenet-inc.com>
To: Krishna Yellepeddy/Austin/IBM@IBMUS
Cc: "'kmip@lists.oasis-open.org'" <kmip@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.
Denis.Pochuev@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.






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]