[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [kmip] Clarification of alternative 3 in my last email
Nope, that covers it. On Wed, May 2, 2012 at 9:05 AM, <robert.griffin@rsa.com> wrote: > 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 > > > > > > > > > > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn: http://linkd.in/OASISopen Twitter: http://twitter.com/OASISopen Facebook: http://facebook.com/oasis.open
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]