OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [kmip] OASIS staff reply on 7 Dec KMIP interop policy discussion

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 
Skype: markjoseph_sc 

From: Jamie Clark <jamie.clark@oasis-open.org>
To: <kmip@lists.oasis-open.org>, Tony Cox <tony.cox@cryptsoft.com>, <Judith.Furlong@dell.com>
Cc: Chet Ensign <chet.ensign@oasis-open.org>, Carol Geyer <carol.geyer@oasis-open.org>, Gershon Janssen <gershonjanssen@qroot.com>
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

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


[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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]