Re: [pkcs11] Re: [GRAYMAIL] [pkcs11] Proposal: Standing Rule for Identifier Allocation

[Valerie Fenwick <valerie.fenwick@oracle.com>]

Yes and no. They could go unused forever, but we already have gaps in our 
constant identifiers, probably for similar reasons. They would not be 
"allocated", as that previous thing would not exist in the standard. There's 
always a risk, that some vendor may much very very quickly, even though was are 
approved and did not end up in the standard. That is why that I left it  to 
cochairs discretion on whether or not to reallocate the numbers

Make sense?

Valerie

On 6/6/2016 4:34 PM, Mark Joseph wrote:
> So if a proposal is rejected  its constants could still remain allocated right?    Why would we want that?
>
> Best,
> Mark Joseph
> P6R,  Inc
> 408-205-0361
> mark@p6r.com
>
>
> > On Jun 6, 2016, at 4:23 PM, Valerie Fenwick <valerie.fenwick@oracle.com> wrote:
> >
> > Hi folks!
> >
> > Here is my rough draft of a standing rule proposal.
> >
> > PKCS11 Technical Committee Standing Rule on Identifier Allocation
> >
> > The PKCS11 technical specifications have several constants defined throughout the standard. Those constants are then used to create the header files for each version of the standard. There is a need for these values to be stable in order to maintain compatibility between various versions of the standard, and interoperability between various vendors and applications.
> >
> > To assist developers who are working on testing new additions to the standard and for interoperability testing, it is important to stabilize the identifiers used for these constants as early in the process as possible.
> >
> > After a proposal has gone through its review process, but before it goes to ballot or voice vote, the proposal author(s) should seek identifier values for all of their constants from the technical committee co-chairs before the ballot is opened.
> >
> > If a proposal is not approved by the technical committee, it will be the co-chairs discretion whether or not to reuse those constant identifier values for a future proposal.
> >
> > Section 2.9 of the TC process covers these rules, see this link for more details:
> > https://www.oasis-open.org/policies-guidelines/tc-process#procedure
> >
> > Thank you for your review!
> >
> > Valerie
> > --
> > Note: I am using voice recognition software. Forgive any strange words.
> > Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
> > Solaris Cryptographic & Key Management Technologies, Manager
> > Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--
Note: I am using voice recognition software. Forgive any strange words.
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.