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

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


We have found from our experience with our last go round that waiting until just before the specification is ratified was too late. Because of vendors time-to-market, and our desire to do interoperability testing, and the length of time it actually takes to code all of these changes, write tests, etc. that stability is desired in these numbers.

I'm sorry if I'm just not getting it, but I'm not sure how this causes additional work for the editors. It should hopefully be cut-and-paste, for just the identifiers. I know the rest the prose often need a lot more massaging to get them to fit correctly in the document, have correct grammar, spelling, and to be in the right section, but I don't recall even the identifier names changing after a ballot.

This is more so that what goes through the ballot, which people certainly do reference while they are waiting for a new version of the standard to come out, is correct.

Valerie



On 6/6/2016 4:57 PM, Chris Zimman wrote:
Not into this at all.  As I've said numerous times, you're just making
unnecessary work for the editors by doing this.  Why assign a number before it
passes ballot?  I have a very hard time buying that anyone is going to include
anything in their P11 implementation before it even passes ballot or voice
vote.  To me, it makes no more sense than allowing submissions to specify their
section or page numbers.

For the avoidance of doubt, my suggestion was that the numbering is done by the
editors after the suggested text passes ballot, but before ratification of the
final spec.

--Chris

On Jun 6, 2016 7:44 PM, "Valerie Fenwick" <valerie.fenwick@oracle.com
<mailto:valerie.fenwick@oracle.com>> wrote:

    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 <tel:408-205-0361>
        mark@p6r.com <mailto:mark@p6r.com>


            On Jun 6, 2016, at 4:23 PM, Valerie Fenwick
            <valerie.fenwick@oracle.com <mailto: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.

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]