Status of vote on the course of the EKMI TC

[Arshad Noor <arshad.noor@strongauth.com>]

Now that the ballot has closed, here are the results and comments
of the ballot.  I'm documenting this in an e-mail to the TC, since
the software running OASIS' site does not show the entire comment
of the voter on the public side.  (The public page for the ballot
is at: http://www.oasis-open.org/committees/ballot.php?id=1658).

Total number of eligible voters: 18
Number that actually voted: 10
Distribution of votes (in the order of majority):

1) Continue independent of the KMIP TC without changing anything:

	6 votes, by the following people:

	Tim Bruce, CA
	Tomas Gustaavson, PrimeKey Solutions
	Marc Massar
	Anil Saldhana, Red Hat
	Shahid Sharif
	Benjamin Tomhave
	
2) Shutdown the EKMI TC:

	3 votes, by the following people:

	Ken Adler
	Arshad Noor, StrongAuth, Inc.
	Davi Ottenheimer

3) Merge with the KMI TC when it is formed:

	1 vote, by the following individual:

	Stephan Drees

Here are the comments supplied by the voters:

--------------------------------------------------------
Ken Adler

KMIP TC's lack of engagement with EKMI suggests that a merge is not 
likely to be entertained seriously by KMIP.

--------------------------------------------------------
Tim Bruce, CA

I would not assume anything about the work or outcome of the KMIP TC, 
and therefore it would not serve those who have worked so hard on the 
EKMI TC, OASIS, or the industry to see the EKMI TC discontinue its work 
at this time. The KMIP TC may ultimately progress and offer an 
outstanding standard that either competes directly with or compliments 
the EKMI TC' work, but in either case OASIS and our industry benefits. 
If the KMIP TC should fail to deliver, it would be unfortunate if we 
were left with no standard going forward.

I understand the comments that have been made relative to the personal 
time and effort invested in the EKMI TC up until now, and that there is 
a concern that further investments in the TC could ultimately be wasted 
time, but there was always the possibility that a competing standard 
could become the one the industry embraces. Even the IEEE 1619.3 
initiative, while assumed to be a binary protocol in its initial 
efforts, was always a potential competitive standard.

If you believe in the product of the EKMI TC, then you believe it can 
stand the test of competitive approaches and initiatives. I was late 
getting into the EKMI TC, and so I have less blood and sweat invested 
(actually, no real blood or sweat so far anyway). As such, my plans are 
to stay with the EKMI TC but to also join the KMIP TC as well. My goal 
is to see that a standard gets adopted, and as such I will hold my 
judgement about what the KMIP TC is or is not going to do relative to 
the work of the EKMI TC. The EKMI TC is far ahead of the KMIP TC, and 
therefore while the KMIP TC goes through its initial struggles the EKMI 
TC has the opportunity to improve upon its work making it more and more 
difficult for a competing standard to evolve. I do believe that the EKMI 
TC needs to look beyond the focus it has had over the years, and 
understand the concerns and motivations of other competing standards 
initiatives to understand how the EKMI work might benefit by adopting 
and adapting to a slightly broader scope in the key management space. 
Such a adaptation could ultimately lead to the KMIP TC disolving or 
merging with the EKMI TC, it is simply too early to say what outcome is 
the most likely outcome.

--------------------------------------------------------
Tomas Gustaavson, PrimeKey Solutions

Even though KMIP have better corporate backing I think EKMI have a head 
start and is more suitable for the enterprise key management, while KMIP 
might be suitable for storage. Therefore I think it's better for SKSML 
to be a standard then to not be. It naturally requires continued time 
invested by a TC chair and I see this involvement as an immediate threat 
to the TC. If no one steps up we might end up shutting down anyhow.

--------------------------------------------------------
Arshad Noor, StrongAuth, Inc.

I believe the policies at OASIS makes it difficult to put out a coherent 
message that benefits users in the IT industry.

In light of the following facts:

*) that charter members of the KMIP TC chose not to engage with the EKMI 
TC despite observing its activities for over two years;
*) that some of them were surreptitiously working on a different 
protocol while giving the appearance of engaging with another industry 
standards group;
*) that OASIS facilitated the creation of a new TC with overlapping 
charters rather than encourage charter members of the KMIP TC to engage 
in a constructive discussion with an existing OASIS TC that has a 
Committee Specification; and
*) that there is nothing in OASIS policy to prevent yet another splinter 
group from the KMIP charter members to start yet another KM-related TC 
within OASIS, if it serves the splinter group' purposes

it appears that OASIS' policies are more sympathetic to IT vendors than 
to IT customers.

In light of this, I believe that the KM industry is better served by 
having the EKMI vision evolve in the "do-or-die" competitive environment 
of the global open-source community, where technology and standards are 
largely driven by IT users than by vendors.

--------------------------------------------------------
Davi Ottenheimer

OASIS has taken the position it serves no purpose but to be a fee-based 
platform for competition with no interest in trying to avoid discord and 
waste among members. Yet by the same token competitors to OASIS offer 
more services without fees. The lack of fees also removes the risk of 
bias towards deep-pocketed corporate entities. What then, by their own 
definition of open competition, becomes the value of OASIS?

--------------------------------------------------------
Anil Saldhana, Red Hat

EKMI can continue with its charter/work and collaborate with KMIP in any 
manner possible when opportunities/needs arise.

--------------------------------------------------------
Shahid Sharif

We should contiue with our work as no one knows if KMIP will ever take 
off even though it has pretty heavy weights behind it. Time will tell.

--------------------------------------------------------
Benjamin Tomhave

We should also engage KMIP, perhaps even through a formal sub-committee. 
If they're only interested in a key management protocol, then there may 
be an opportunity to collaborate on the other work we've already initiated.