OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[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]