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: re-chartering KMIP


Re "Chet, is that reasonably accurate?" -- yes, you have stated it well. 

The KMIP TC is working through what I've seen several other TCs tackle recently - after x years of working on the problem they set out to solve, they have a better understanding and want to change the charter to reflect the mature perspective. Same thing goes on in other organizations as well. Sometimes it is just clarifying the charter to clear up ambiguities - other times it is rechartering to adjust the scope. 

My sense from the ongoing discussions is that you are all doing fine with it. 

Best, 

/chet 


On Tue, Mar 19, 2013 at 9:29 AM, Griffin, Robert <robert.griffin@rsa.com> wrote:

Hi John,

 

Thanks for going through my email and the charter so carefully! 

 

I think it’s true that we might not need to update the charter for the work we’re doing in V1.2, given exactly the language used there currently (the use of “initial” that you pointed out, for example).  I actually think that’s true of the crypto services as well; Chet’s guidance in the charter discussion was that things not explicitly declared out-of-scope, but reasonably related to in-scope items, are in-scope for the TC. That is, the default is inclusion of (reasonably related) things not declared out of scope, rather than exclusion of things not declared in-scope. Something like this:

 

“The out-of-scope list sets your boundaries and anything not listed there can be considered in scope. Anything reasonably related to the problem scope the TC is tackling can be considered in scope.”  Chet, is that reasonably accurate?

 

But over the past couple of years we have gradually come to see that things we thought were at best tangential to the protocol, like client registration, are coming up more and more often – not just as context but as things that need to  influence and maybe be represented in the protocol. So I think it would be a good idea to acknowledge that we do want to at least consider things like server-to-server and client registration that were excluded in the initial work of the committee, as well as things like crypto services that were not mentioned at all. Hence my urging that we revise the charter. It’s certainly fine with me to be more specific that things are in-scope; it just seemed to me that removing the out-of-scope items that are in conflict with stuff we want to work on was the simplest way forward?

 

Assuming we do revise the charter, it would make a lot of sense to clean up the language in the various places you’ve called out. Thanks again for pointing those out!

 

I’m looking forward to continuing this discussion on Thursday.

 

Regards,

Bob  

 

From: John Leiseboer [mailto:JL@quintessencelabs.com]
Sent: Monday, March 18, 2013 10:57 PM
To: Griffin, Robert; kmip@lists.oasis-open.org
Subject: RE: re-chartering KMIP

 

Hi everyone,

 

I just found time to properly read the current charter with a legal eye. I found the following interesting.

 

Section talking about the initial goal of the TC:

 

“The initial goal is ... Out of scope areas include: ... registration of clients, server-to-server communication and key migration ...”

 

And towards the end, where in scope items of KMIP are described:

 

“KMIP ... will be scoped to include the following: ... actor discovery and enrolment, ... key, certificate and policy migration ...”

 

I read this to mean that only the initial scope excludes registration of clients, etc. But the full scope of KMIP (beyond initial) includes registration of clients (“actor discovery and enrolment”), etc. Does anyone have a legal opinion on this that is different to mine?

 

This is not a reason to abandon the charter change work, but I think it warrants us better understanding what really is in and out of scope. For example, in my reading of the in scope section of the charter, I see nothing that allows us to include the crypto operations. Neither is there an explicit statement that directly says we cannot. But the only sensible interpretation of the charter would be that items not specifically included (where such items could be interpreted to go beyond the scope of key management) are by default excluded. (I think the crypto operations proposal is the only one that would be out of scope given this interpretation. Everything else we’ve been considering for 1.2 is in scope.)

 

So while we’re looking at these changes to the charter, and if we’re also wanting to add crypto operations, I think we at least need to have the discussion on whether we need to also change the charter to specifically include cryptographic operations as in scope. And possibly, this would the only reason that we need to change the charter.

 

John

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Griffin, Robert
Sent: Tuesday, 19 March 2013 3:25 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] re-chartering KMIP

 

Hi (yet again!) –

At the KMIP F2F, the TC agreed that we’d like to move ahead with considering re-chartering the TC. I asked Chet if we needed to wait until the V1.1 Errata are done before starting the process; he didn’t think so (“You would work on the Errata under either version of the charter”). So I’d like to discuss the following draft motion in our call this week: 

 

“I move that the KMIP TC request OASIS administration to initiate a special majority ballot to determine whether the KMIP TC wishes to modify the current charter, such that the following bulleted items are removed from the list of out-of-scope areas currently defined in the charter:

 ·  Framework interfaces not dedicated to secure key and certificate management

·  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.”

 

A couple of things I’d call out:

-           Chet felt that this motion didn’t need to be a ballot, since OASIS will be setting up a Special Majority ballot.

-           

-          I assume that some or many of the member organizations will need to have their legal departments review this change to the charter. So we probably want to wait to make and vote on this motion until such review has taken place? Should we have a statement of intent that folks can take back to their companies?

Regards,

Bob

 

 

The motion is fine. You can just approve it as a motion in a meeting if you want to. No need for you to create a ballot (7 days) to ask me to initiate a ballot (7 more days). Then (since we don't have a ticket for this) just send me the link in an email and I'll set the ballot up.  

 

 

--




--

/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 

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

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]