[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: proposal for KMIP TC V1.2 charter straw poll
Hi – For the straw poll regarding the KMIP TC charter, how about something like the following (for discussion in our call tomorrow): Question: Which approach to the KMIP TC charter for V1.2 are acceptable to you? Description: Please indicate which, if any, of the three choices below are acceptable to you. Option 1: no change to current charter. We would exclude server-to-server (both enterprise and cloud), key migration (again, both enterprise and cloud) and client registration from V1.2 and subsequent versions of KMIP. Option 2: revise KMIP TC charter to remove the following bullet from the “out-of-scope” items: “Certain areas of functionality related to key management are also outside the scope of this technical committee, in particular registration of clients, server-to-server communication and key migration.” This revision of the charter will require a confirmation-of-contribution letter from all current and past KMIP TC member organizations. Option 3: create a new KMIP TC, adopting KMIP V1.1 documents as contributions, with the current KMIP TC charter minus the bullet listed in Option 2. Regards, From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of robert.griffin@rsa.com Hi – As we discussed in our last call, if we go with the second option below, then it looks like we would need a statement of contribution from each organization with current or past members in the KMIP TC. Here’s a quick cut at what such a statement might look like: Company information Contact name Date [company] hereby confirms that all Contributions made to date by [company] to OASIS Key Management Interoperability Protocol (KM IP) Technical Committee for possible consideration in the OASIS KMIP standard are contributed to the KMIP TC as re-chartered, according to the IPR Policy for the originally chartered KMIP TC and the re-chartered KMIP TC.. [company] grants to OASIS a perpetual, irrevocable, non-exclusive, royalty-free, worldwide copyright license, with the right to directly and indirectly sublicense, to copy, publish, and distribute the Contribution in any way, and to prepare derivative works that are based on or incorporate all or part of the Contribution solely for the purpose of developing and promoting the OASIS Deliverable and enabling (subject to the rights of the owners of any Essential Claims) the implementation of the same by Licensees or Beneficiaries. I haven’t run this by any legal folks yet. I based it on the language in the OASIS Intellectual Property Rights (IPR) Policy at http://www.oasis-open.org/policies-guidelines/ipr. Regards, Bob From: Griffin, Robert hi – In prep for our discussion of the charter in our KMIP TC call tomorrow, here are my thoughts on our alternatives moving forward. I think there are 2 statements in the current charter, both in the “out-of-scope” section, that are in substantive conflict with topics we are considering for V1.2. Here they are: • Certain areas of functionality related to key management are also outside the scope of this technical committee, in particular registration of clients, server-to-server communication and key migration. • Bindings other than tag-length-value wire protocol and XSD-based encodings In the first of these two statements, all 3 excluded areas of functionality are relevant for the use cases we’re discussing for V1.2, particularly registration (Stan), server-to-server (Bob L.) and cloud (Bob G.). The second of these statements is in potential conflict with _expression_ of the KMIP protocol in formats other than TTLV and XML. This may be an issue if we create a normative _expression_ of the protocol in JSON, for example. At this point, I think our alternatives boil down to 3 major choices: 1. We limit the functionality we introduce in the next version of KMIP to those things that are within the scope of the current charter. There are certainly valuable things for us to do that do not impinge on the statements above; I believe this would be true of the PGP use cases, the QKD use cases and probably the admin use cases. 2. We re-charter the KMIP TC as described by Chet in our 5-April meeting (see the minutes of that meeting as posted in the Calendar folder of our KMIP document repository), requesting all TC members to confirm their contributions to KMIP as contributions to the re-chartered TC. 3. We create a new TC. That is, upon completion of KMIP V1.1 (including approval of the V1.1 documents as OASIS standards), we close the KMIP TC and create a new TC (for example, “eXtended KMIP”) with a revised charter, contributing only the V1.1 final documents in the creation of that TC. For our call tomorrow, I’d like to discuss these alternatives, flesh out the pros and cons of each one and determine if there are any other alternatives we should consider. Chet will be joining us on the call to help in clarifying the alternatives and their implications. I do not expect we will vote on any these alternatives tomorrow; I think we will want to take some time to reflect on them before making a decision. Regards, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]