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

All -

I would like to suggest that as this year's RSA event approaches, we consider the following changes to to the interop rules.

Note that none of these actions would prevent a paid member from attending RSA, but they incentivize the members to participate in the testing process and be on time.

Rick Robinson
Offering Manager
Encryption and Key Management
IBM Corporation | IBM Security
720.349.5030 | rick.robinson@us.ibm.com

Inactive hide details for Andre Dexter Bereza ---12/14/2017 11:32:00 AM---Hi Jamie and everyone, I'm André "Dexter" from KryptuAndre Dexter Bereza ---12/14/2017 11:32:00 AM---Hi Jamie and everyone, I'm André "Dexter" from Kryptus Information Security, an HSM manufacturer loc

From: Andre Dexter Bereza <dexter@kryptus.com>
To: Jamie Clark <jamie.clark@oasis-open.org>, 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>
Date: 12/14/2017 11:32 AM
Subject: Re: [kmip] OASIS staff reply on 7 Dec KMIP interop policy discussion
Sent by: <kmip@lists.oasis-open.org>

Hi Jamie and everyone,

I'm André "Dexter" from Kryptus Information Security, an HSM manufacturer located in Brazil. Here at Kryptus answer directly to our board, leading the development of all products and services. I also represent Kryptus in everything related to OASIS and the KMIP TC.

We joined OASIS in 2016 specifically to participate in the KMIP Interop demonstration at RSAc. It was our first time in the event.

When we started to work to make things happen in the Interop we were very disappointed, because we didn't feel all participants were taking the tests seriously. We had companies that: didn't replied our e-mails in a timely manner; didn't seem to put the effort in to making the tests work; didn't show up in the Interop meetings to check the results; arrived in the show floor extremely late (after 2PM); didn't have the servers/clients working in the first day; didn't bring the exact implementation used in the tests. I can probably dig in and find more examples, but I think this is enough.

We were the rookies in all of this, so we didn't know whether this was normal or something was very wrong. Anyway, we were disappointed, because it was not what we expected from the Interop demo.

Kryptus believes that changes have to be made:
- If OASIS decides that ejection from the show floor is allowed, we will agree with it
- Although the badge system proposed by Carol seems to be nice, we don't think it will have the desired effect
- Placing companies that didn't meet the criteria in another location seems troublesome, especially if they don't bring the implementation to the show floor or something like it, but we think it will be more effective than the badge
- We believe that a more popular approach will be to not allow the company to participate in the next Interop demo if they don't meet the criteria in the current event

Kryptus agrees that those long discussions about the Interop should happen in another time. The KMIP TC has several matters to discuss regarding KMIP 1.4 and 2.0, and we are not able to do that with the Interop discussion happening, especially if things go like the last weeks call.

On a final note, Kryptus is part of the KMIP TC and we felt disrespected by the personal tone used to address Mr. Tony Cox and Cryptsoft. The draft letter is not something that was made by Tony Cox and Judy Furlong themselves, I personally gave input for some of the things that troubled me in the Interop demo that helped fuel the discussion. Addressing them personally is taking Kryptus out of the picture and that is not something we expected to happen in the OASIS environment.


André "Dexter" Bereza,
Technical Manager
Trust in Cybersecurity
+55 19 3112 5000

On 12/12/2017 05:47, Jamie Clark wrote:
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_staff&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Dmp4_W9Bc07s8ayLUi9QWHbqJGdlTSPxeaYJsg3UWNM&m=mLOb5xgRIjSIjLIRtyRQWpKz1d7P1J_9kfmCvU7wBc8&s=p4RKl6oWUFp2XbSZC61LhigmqsH-eJVNYOvNsHgqAec&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_staff&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Dmp4_W9Bc07s8ayLUi9QWHbqJGdlTSPxeaYJsg3UWNM&m=mLOb5xgRIjSIjLIRtyRQWpKz1d7P1J_9kfmCvU7wBc8&s=p4RKl6oWUFp2XbSZC61LhigmqsH-eJVNYOvNsHgqAec&e=>
www.twitter.com/JamieXML <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_JamieXML&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Dmp4_W9Bc07s8ayLUi9QWHbqJGdlTSPxeaYJsg3UWNM&m=mLOb5xgRIjSIjLIRtyRQWpKz1d7P1J_9kfmCvU7wBc8&s=M_k10a8pVJmWdDuWh5_61wd3FkFGE_R-b7jfDAuCqSI&e=>
> //
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.oasis-2Dopen.org_archives_kmip_201712_msg00005.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Dmp4_W9Bc07s8ayLUi9QWHbqJGdlTSPxeaYJsg3UWNM&m=mLOb5xgRIjSIjLIRtyRQWpKz1d7P1J_9kfmCvU7wBc8&s=lkOJiYVrvNxGPdI9OxrQ45Xi_BYMMq3-3o3WHIGd2Mo&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.oasis-2Dopen.org_archives_kmip_201712_msg00005.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Dmp4_W9Bc07s8ayLUi9QWHbqJGdlTSPxeaYJsg3UWNM&m=mLOb5xgRIjSIjLIRtyRQWpKz1d7P1J_9kfmCvU7wBc8&s=lkOJiYVrvNxGPdI9OxrQ45Xi_BYMMq3-3o3WHIGd2Mo&e=>   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://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_policies-2Dguidelines_interop&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Dmp4_W9Bc07s8ayLUi9QWHbqJGdlTSPxeaYJsg3UWNM&m=mLOb5xgRIjSIjLIRtyRQWpKz1d7P1J_9kfmCvU7wBc8&s=eRwRTcC8H66fRh3PF1aj1XOE_72CtJTFXu6If3IX2Sw&e=.  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://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_committees_download.php_59127_KMIP-2520Formal-2520Interop-2520Process-2DV1.4a-2520-28Oct2016-29.doc&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Dmp4_W9Bc07s8ayLUi9QWHbqJGdlTSPxeaYJsg3UWNM&m=mLOb5xgRIjSIjLIRtyRQWpKz1d7P1J_9kfmCvU7wBc8&s=qSZrU3vcEti8fLskxE4kywXopqX5tPRNXIYexn-8T5c&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.oasis-2Dopen.org_committees_download.php_59127_KMIP-2520Formal-2520Interop-2520Process-2DV1.4a-2520-2528Oct2016-2529.doc&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Dmp4_W9Bc07s8ayLUi9QWHbqJGdlTSPxeaYJsg3UWNM&m=mLOb5xgRIjSIjLIRtyRQWpKz1d7P1J_9kfmCvU7wBc8&s=9W1SY-ZntQ-giQwAItLZhllm16YerbkVBSnS2Zdzy5E&e=>
> [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.

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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