looking back at V1.1, looking forward to V1.2

Hi –

By way of context, here are some of the major milestones for our V1.1 work:

- September 2010: kicked off V1.1 work at our face-to-face meeting. Topics included access control (Marko V.), group object (Krishna Y.), key wrapping (Indra F. / Stan F.), interop testing (Mathias B.), client registration (Alan F.), storage client profile (Gordon A.), laptop encryption profile (Mike A.), trust establishment (Judy F.), server-to-server (Robert H.) and SNIA interop testing (Gordon A.). Also passed asymmetric key profiles (ballot, not at f2f).

- February 2011: re-scoped V1.1 at face-to-face to focus on interoperability, to include vendor extension, version negotiation, corrections for cert length etc ; also continued work on client registration, groups and access control.

- December 2011: KMIP V1.1 submitted for public review

- February 2012: review of public comments and revisions for KMIP V1.1 at face-to-face. V1.1 interop at RSA conference.

- May 2012: Following work on attribute index, profiles etc, KMIP V1.1 submitted for second public review

- July 2012: vote to approve V1.1 docs as Committee Specs/Notes

- September 2012: Committee Spec/Note URLS available; SoUs submitted

In thinking back on the V1.1 schedule, a couple of things struck me:

- Our face-to-face meetings had a critical role as forcing functions in moving our work forward. Planning on regular face-to-face meetings at something like 6-month interval could help us in maintaining momentum in our work on V1.2.

- The cadence of weekly concalls was also important in helping us to move forward. Though it was worth trying bi-weekly meetings, we should continue with a weekly schedule, again to help us in maintaining momentum.

- The interop process was also an important driver/factor in moving forward, for example in showing up issues/concerns in the protocol and proposals. Can we can increase participation in that process and get feedback on proposals more quickly? Will specifying test cases as well as usage guide implications in any proposal being voted on.

- Re-scoping had a significant impact on V1.1. We should be careful about our scoping decisions – including in ensuring that we have clear drivers for including functionality in V1.2, such as clear expectations/commitments about implementation and interop testing of proposed new functionality.

- We tended to work on proposals one at a time; are there ways to increase parallel activity on proposals?

I’d like to discuss these ideas and any others that you have about what we can do as a group (as well as Subhash and I as co-chairs) to work more effectively. Looking forward to talking to you soon!

Regards,

Bob

kmip message