Hi Jamie,
We have never meet. Let me introduce myself. I represent P6R and we have a Sponsor Level Membership in OASIS. We are members of the KMIP TC and the PKCS#11 TC. My company, of which I am one of the founders, produces and sells products based on the KMIP and PKCS#11 standards. We have been involved with OASIS and KMIP for 4 years now. And we have taken part in 3 of the last 4 KMIP interops. I am also one of the developers in my small company so I have actually produced part of the KMIP code and test cases that are required for the interop. Myself and my company have spent a lot of resources to take part and do well in the interops. The other interesting thing is I would say we are direct competitors to Cryptsoft in the KMIP market. Yet during the OASIS process and interop we work just fine with them. Cryptsoft even helped us get started with all the KMIP testing even though it was clear we would end up being their competitor.
One thing that has troubled me in your last couple of emails and certainly during last week's KMIP call (of which I took part) was the strange way you have singled out Cryptsoft as if it has all been their idea. During the call last week I could not believe my ears when you actually said you thought Tony Cox has set people up to talk supporting his point. I was one of those individuals and I took that quite personally. I assure you no one told me what to say and I have worked with Tony a long time and he would not do that. But the fact that you even mentioning that was very unprofessional.
From P6R's point of view, we need a rigorous interop process to show to our future customers that our product meets the KMIP standard and works with other implementations. Otherwise there is simply no reason to spend our money to be part of OASIS. In the past I have recommended OASIS to my friends companies but at this point I can't see doing that. Companies that take part in the interop must meet some basic set of rules which have been defined and agreed to each year by every participating member. If they cannot meet those requirements then they should not participate and make room for companies that are serious about the standard. P6R has mentioned this to OASIS members at the RSA show each year. None of this is new and Cryptsoft is not the only TC member that feels strongly about this.
Best Regards,
Mark Joseph, Ph.D.
President
P6R, Inc
408-205-0361
Skype: markjoseph_sc
http://www.linkedin.com/pub/mark-joseph/0/752/4b4
From:
Jamie Clark <>
To:
<>, Tony Cox <>, <>
Cc:
Chet Ensign <>, Carol Geyer <>, Gershon Janssen <>
Sent:
12/11/2017 11:47 PM
Subject:
[kmip] OASIS staff reply on 7 Dec KMIP interop policy discussion
Dear members of the KMIP TC.
This is a follow-up to our conversation at your TC meeting on 7 December. OASIS staff asked you to
postpone final action on your 2018 interop event until at least 14 December, so that
we can pass along the thoughts stated in this
letter, and gather your feedback on the rule issue described below. We appreciate the TC's being willing to do so. We plan to
attend your meeting on 14 December to answer any further questions that the TC members may have.
The
TC received a proposal from Tony Cox, on the day before the last meeting,
advocating that the TC decide not to run an formal interop demo in 2018 [1], because of OASIS' prohibition of ejections from the show floor in the current version of our Interop Rules [2]. The draft names that single point of disagreement as the reason to cancel a formal test for 2018.[3] The draft at least inferentially leaves open the possibility of other events for 2018.
As we understood it, Mr. Cox's draft [4] proposed the position
that the KMIP Interop Demo event cannot be conducted properly, without the ability to eject registered participants at show time if they fail to meet certain milestones, with an exception for any members that the TC votes specially to retain.[7]
At
your meeting on the 7th, we did not feel that we heard many of the TC
member companies express views on that specific issue. So this
message is designed to provide background, and solicit your further
input as TC members.
To summarize:
As you know, each TC is encouraged to adopt its own set of "local rules" [5] to specify test methods, timing, content, and consequences. The KMIP TC needs to do so for the 2018 event soon, which drives this conversation's timing,
We
believe there has been good faith disagreement, for several years,
between our staff and the KMIP test administrators, about whether a TC's "local rules" should require ejection [6] of failing test
participants from the RSA
show floor. Our 2017 policy revision attempted to clarify this
point.
All testing participants
are disadvantaged, if individual registrants repeatedly decline to
participate
fully or timely -- with the results that the efforts of all participants
to fill the testing matrix may be forced to limp along without success,
causing all parties a difficult
technical rush at the end. So it's reasonable if the TC wishes to adopt
appropriate rules to address that risk.
However,
OASIS' staff view is that neither we, nor the TC, nor its
volunteer test administrators, ought to be in a position of
making discretionary subjective value judgments about registrants, nor to make last minute ejections on site.[7] Our preferred approach is to publish and apply objective criteria, against which any registrant can
be measured well in advance of any dispute on the show floor, and which are applied equally to all registrants without discretionary exceptions.
We
have suggested several alternatives, described below, for TC "local rules" to address any continuing
problematic failures, in ways that we believe are consistent with OASIS policy.
The TC may wish to consider imposing rules, at the start of the testing
cycle (that is, now, for the 2018 event), that state clearly that a registrant will:
not be admitted to the event demo, based on determinations made well in advance of the event, for which all registrants have ample notice, or
suffer a reduced or differently-captioned presence, or
enjoy different permissions or lead access at the test event, so that their status is not misrepresented by their presence,
in
each case based on specific failures to meet stated objective
milestones at certain times. OASIS staff believe that such cases are
rare, but could be handled appropriately by objective
approaches of that kind, if they arise. Our policy does state that staff still retains the right to review any such proposed rules for fairness. But rule-based
objective approaches generally are easier to administer fairly, and also are less likely to generate last-minute disputes at the physical show floor event.
For example:
The
TC might decide that, if any test applicant has participated X times
in past years, and failed to meet certain (or all) of the test milestones
in each of those X years, then they may be deemed ineligible to participate in the next year's event, from the start.
Also,
the TC might decide that any registered parties who fail (using
objective criteria specified in advance) to meet X milestones during the
year's test protocol must be located physically separately, with
different signage, than other registrants.
Obviously,
a rule that relies on past year performance would not apply to new entrants who have not participated in prior
years.
We believe that rules of that type could appropriately be inserted
into your TC's "local rule" resolution for the 2018 event. If the TC
feels that these are desirable steps, but that the change would provide insufficient notice to registrants for the April 2018 event, the TC also
could elect to make the changes effective for 2019.
OASIS
has no views on whether such rules to address difficult cases are
likely to be needed, in your TC. However, we believe we should support the
TC's preference, so long as it is based on objective criteria, measured with specificity and in advance.
The
foregoing options directly address question raised by two
members at your December 7 meeting about what other options, than
ejection from the floor, may be available to address cases of continued
problematic failure. It
remains for the TC, through each of its members, to assess our suggestions, and decide how the TC would
like to proceed with a testing plan, and with what consequences for test failure, in light of our current policy.
Please
note, the consortium-level Interop Demo Policy is a creation of our staff. We're human, so we also must be open to feedback suggesting
that our policy choices are flawed. If a
significant independent number of TC members believe that our view on last-minute ejection
is wrong, we want to hear that, and I expect our Board does as well. We invite participating companies and experts to
discuss these issues further within the TC, but also welcome anyone who wishes to communicate their views to us directly, either through our
staff or our Board chair, Gershon Janssen, who is copied here.
Thank
you for your attention, and bearing through this long communication.
Ultimately, all such events and programs are voluntary, like open
standards themselves, and rely on the good will of the participants. We welcome your feedback both negative and
positive on how best to administer them.
Cordially Jamie
James Bryce Clark, General Counsel
OASIS: Advancing open standards for the information society
https://www.oasis-open.org/staff
www.twitter.com/JamieXML
OASIS+FIRST.org Borderless Cyber Prague Dec 2017: j.mp/praguecybersec
EU Commission Rolling Plan for Open ICT Standards: j.mp/EUstds2017
Cybersecurity standards at RSAc 2017: j.mp/OASIS2017RSA
FOOTNOTE REFERENCES
[1] Mr, Cox's 7 Dec proposal to the TC can be found here: https://lists.oasis-open.org/archives/kmip/201712/msg00005.html From the 8th paragraph of that draft: "KMIP TC finds itself unable to endorse or support an Interop Demonstration[.]"
[2] The OASIS consortium-level policy can be found at: https://www.oasis-open.org/policies-guidelines/interop. Its Section 7.2 was revised in February 2017 to state that a member who simply fails the test matrix "retains the option to showcase its product." This is the policy position with which Mr. Cox's letter disagrees.
[3] From Mr, Cox's 7 Dec draft, 2nd paragraph: "However, we have now reached an impasse over one particular issue."
[4] Mr, Cox's 7 Dec draft, in its 3rd paragraph, says: "OASIS Staff firmly believe that a member shall
never be able to be precluded from participation in an Interop
Demonstration even if the technical or behaviour requirements have not
been met." OASIS staff does not see our position the same way -- please see footnote [6].
[5] The TC's adopted local rules" for last year's
event, dated October 2016 for the February 2017 RSA conference, called
the "KMIP Formal Interop Process v1.4a," which can be found here: https://www.oasis-open.org/committees/download.php/59127/KMIP%20Formal%20Interop%20Process-V1.4a%20(Oct2016).doc
[6] Please note, OASIS staff does not rule out the possibility that extraordinary bad behavior might result in staff ejecting a participant. Imagine, for example, someone who started a fight on the show floor, or sabotaged some other member's device. The point of our policy is that mere failure to pass the test, measured immediately before the show opens and subject to a discretionary free pass from the TC, is an insufficiently-objective and poorly-timed.approach.
[7] Section 4.1.1 of the KMIP 2016 local rules would eject all registrants who fail the interop
tests, but with a special exception for any that the TC and the test
group choose to invite back to the show floor by a special
majority
vote. OASIS staff sees that as a subjective and thus problematic
approach. We acknowledge that the TC enacted such a rule in prior
years. Staff simply should have noticed and raised that issue earlier.
