thoughts on kmip tc charter

[<robert.griffin@rsa.com>]

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,

Bob