I can’t say I disagree with the points being made. I think it all goes down to the goal of the
I in KMIP, how interoperable do we want to make it? Interoperable in a
vertical segment or horizontal across the enterprise? I think what we are
leaning toward the former at the expense of the latter.
The banking scenario is a valid use case. I think if we
went with one minimum server profile we may risk imposing a high cost for
development and conformance or the risk of implementations splintering off from
the standard. If we implement multiple profiles we risk having a
splintered standard, and multiple KMIP standards to chose from.
One option is to limit the profiles to a very small number (2 or
3) with little-or-no option for adding more (at least in 1.0). I think it
would be important to define a full conformance profile (to the minimum as Todd
mentioned) such that no subset profile will require more (to ensure fully
conforming servers support all sub-profiles). This may be improved
with defining two classes of conformance being “full conformance” and
the rest being “profile conformance”, so that the consumers are
very aware of their purchase.
To the comment about switching over from one KMIP Server to
another, I agree with the challenges in server specific designs and I’ll
add that corporate inertia may also go against changing out functioning solutions.
Thanks,
Jay Jacobs
From: Todd Arnold
[mailto:arnoldt@us.ibm.com]
Sent: Friday, August 21, 2009 10:14 AM
To: kmip@lists.oasis-open.org
Subject: RE: [kmip] Broader View of Conformance
The other very
important point to this is that since we have a standard defining how KMIP
works, people should be able to switch from one KMIP server product to another
if they need additional functionality.
Of course, the
caveat here is that our KMIP spec leaves a lot of things up to the server
designer, so they might be different in different implementations. (For
example, there are several things noted in the spec and user guide as
"outside the scope", such as registration of the client with the
server.)
-------------------------------------------------------------------
Todd W. Arnold, STSM
IBM Cryptographic Technology Development
(704) 594-8253 FAX 594-8336
-------------------------------------------------------------------
email: arnoldt@us.ibm.com
|
From:
|
David.Lawson@Emulex.Com
|
|
To:
|
Todd
Arnold/Charlotte/IBM@IBMUS, <kmip@lists.oasis-open.org>
|
|
Date:
|
08/21/2009
10:55 AM
|
|
Subject:
|
RE:
[kmip] Broader View of Conformance
|
Requiring
all KMIP compliant servers to implement most of the KMIP specification would
raise the costs of the users requiring only a single subset of KMIP for their
application. Allowing targeted profiles to support the lower cost, targeted
servers, does not necessarily mean there will be a multitude of KMIP servers
required. If a user requires support of a single profile, a KMIP compliant
server can be purchased that supports just the one profile. If the user wishes
to have a more general purpose KMIP server, he can purchase a server that
supports multiple profiles, approaching the server that supports most of the
KMIP specification.
The
user who requires, or might require in the future, can purchase the KMIP server
that provides support for multiple profiles, or that can be upgraded to support
multiple profiles at a later time. This would prevent the problem of having one
key server for each purpose.
David
Lawson
Emulex
Corporation