Clarification of alternative 3 in my last email

[<robert.griffin@rsa.com>]

Hi –

 

By way of explaining the third alternative< in the email I just sent, here’s a bit more on how it might work:

 

1.  When V1.1 is approved as an OASIS standard (assuming it is), we declare the work of the KMIP TC as complete according to the current charter and close the TC.

 

2.  In parallel with closing KMIP TC, we issue a convener call for a new "eXtended KMIP" (XKMIP?) TC with a revised charter that removes the out-of-scope restrictions, perhaps also making other changes in the charter if participants see a need to, with the same IP policy. We have to provide a new TC name to distinguish the new TC from the preceding TC.

 

3.  In the first meeting, called by the convener, we accept as the only contribution the V1.1 docs (in their form as OASIS standards) or alternatively, accept the responsibility for maintenance of the existing versions of the KMIP standard.

 

4.  From that point on, any member of the new TC can make whatever contributions they want, including things that were discussed in the KMIP TC: for example, the use case docs related to server-to-server, etc.

 

It looks to me that we could continue discussions of server-to-server, cloud, registration and other use cases within the existing KMIP TC without any issues. But we would want to stop short of proposals for enhancing the KMIP protocol to support those use cases until the new TC is established.

 

In discussion regarding this alternatives, Chet pointed out a couple of clarifications for this approach:

 

-    The new TC doesn’t have to have a new name for the protocol, just for the TC.

 

-    The new TC can take on responsibility for maintaining previous versions of the protocol (for example, for an Errata doc or for reviewing profiles that pertain to previous versions). In that case, it would be simplest if in closing the KMIP TC, we handed responsibility for the protocol to the new TC. Taking this approach, we don’t need to formally accept the V1.1 docs as contributions.

 

-    Anyone is free to contribute anything they originally contributed to the new TC and we can reference the original TCs work products without problem.

 

-    In terms of the transition period, we can work determine the target 1st meeting date for the new TC once we have a forecast final date for V1.1. That would let us (and OASIS) leverage the PR around V1.1 reaching OASIS Standard to solicit more participants for the new TC.

 

-    When we close the KMIP TC, we put verbiage on its home page that points people to the new TC so that anyone who happens along to KMIP will be directed to the new work.

 

Chet, anything I’ve forgotten?

 

Regards,

Bob