[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] C_ChangeLabel/C_ClearToken
On 12/06/2013 5:21 AM, Dina Kurktchi wrote: > Respectfully, that approach may not be the right one for the > collection of people in this group. Silence may also mean > "ain't got around it yet" or "nothing to add"; not disinterest. I appreciate the response and recognise the sentiment Dina, but if there is insufficient interest to even indicate off list or on list support for a concept then frankly it will not make the cut for inclusion in v2.40. Each proposal has to have sufficient support to make to to a motion for a ballot, pass a ballot and generally have multiple vendors interested in implementing it and making a statement of use. The way OASIS technical committees work require support for proposals - or simply put things do not move forward - a proposal with no support simply does not get included no matter how nicely written up the proposal actually is. Generally you need at least three organisations who are interested for something to make sense - and not simply two parties who have very different views. There is a lot of communication which occurs off list - but in order to move things forward support has to be shown in the group itself. I know quite a few folks are somewhat hesitant to speak up given the nature of some of the responses which come back. Personally I think we have a huge range of ideas built up over the last decade of problems which PKCS11 does not (yet) tackle well; but I expect that what makes it into the first OASIS release (v2.40) will be relatively modest - that was my sense from the discussions at the face to face and in the meetings. That means the majority of the proposals floated to date are unlikely to be included (where we haven't seen consensus amongst 3+ participants). I could of course be completely wrong - but this is how things normally work in an OASIS context. Along those lines: - if there is interest in an enumerate-all-attributes capability going into v2.40 then speak up (MikeS and TimH have indicated an interest) - is there interest in changing tokens after they have been set up (you have indicated rename is at least important along with being able to destroy all the objects on a token, MikeS has suggested modelling of the HW handling, I've suggested going further allowing updates of everything in CK_TOKEN_INFO, MikeS has indicated his views on that) - is there interest in supporting dynamic creation of slots (e.g. C_CreateSlot, C_DestroySlot) I think if you want to add in renaming tokens and clearing tokens then you want programmatic control over the life-cycle of a token and that goes beyond what you have suggested - and should either be tackled in that context or left alone (and tackled with handling slots as well as tokens for the same reasons). If others agree or disagree who haven't already expressed an opinion on the topic then they need to speak up. Tim.