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
- From: Krishna Yellepeddy <kyellepe@us.ibm.com>
- To: "Pochuev,Denis" <Denis.Pochuev@safenet-inc.com>
- Date: Wed, 18 May 2011 13:21:04 -0500
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]