RE: [SPAM] - [kmip] Broader View of Conformance - Bayesian Filter detected spam

["Zelechoski, Peter" <pzelechoski@essvote.com>]

I do not disagree with what Jay is saying.  I understand the desire to have a more full featured deployment to minimize the number of servers you might otherwise end up with.  Although I can support the more subset centric deployment even if I would prefer a global one.

 

Going this route would be a redirection of what had been the path.  It would require that we define what constitutes the required functions, across all, that would constitute conformance.

---

From: Jay.Jacobs [mailto:Jay.Jacobs@target.com]
Sent: 2009-08-21 9:23 AM
To: kmip@lists.oasis-open.org
Subject: [SPAM] - [kmip] Broader View of Conformance - Bayesian Filter detected spam

I wanted to re-iterate what I talked about on the last conference call in looking at conformance at a higher level.  I have a concern that multiple server profiles will fragment adoption and increase the complexity and/or frailty of interoperability. 

 

Here’s the scenario I’d like to avoid.  Say I purchase a KMIP conforming server for tape devices, then later purchase/upgrade some client product that also claims “KMIP Conformance” but the new client needs a different profile from the server, so I get a second key management server.  After a few iterations I may end up with several KMIP implementations across the enterprise (compounded by any added features from vendor extensions).  The end result is that my key management now looks like the picture of what KMIP is trying to solve: isolated key management instances that can only support a fraction of the clients in my network.

 

Here’s what I would propose, a single KMIP profile for servers, that should support whatever client gets thrown at it.  This makes the server interchangeable in the network.  It will be more work to create a KMIP Server, but there shouldn’t be many of them in an enterprise anyway.  The clients are compliant only in the requests they choose to make.  If a client won’t ever request asymmetric keys, they wouldn’t have a need to support it and it would still be conforming to the standard.

 

Thanks,
Jay Jacobs