kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [kmip] Broader View of Conformance
- From: Todd Arnold <arnoldt@us.ibm.com>
- To: kmip@lists.oasis-open.org
- Date: Fri, 21 Aug 2009 11:13:32 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]