[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [GRAYMAIL] Re: [pkcs11] Re: Re: [pkcs11] Re: [pkcs11] Proposal: Standing Rule for Identifier Allocation
Chris
I respectfully disagree, I shared the summary (reviewed by all involved in the side discussion) with the entire TC, and we additionally have discussed it in 2 TC meetings. We discussed this standing rule proposal in the TC meeting as well before it was drafted.
This topic is again on this week's agenda
Valerie
Sent from my iPhone
> On Jun 7, 2016, at 3:21 AM, Chris Zimman <chris@thdsys.com> wrote:
>
>> On Tue, Jun 07, 2016 at 01:31:33PM +1000, Tim Hudson wrote:
>> And the KMIP approach is very early implementations and Interop testing
>> long before the specification is final. Early identifier allocation and a
>> feedback loop from practical experience.
>
> Nothing precludes the same thing here.
>
>> I understand Chris's view point but I disagree that the editor allocating
>> at the end post-ballot is the right approach. It hasn't worked to date and
>> is very much different to how the faster moving OASIS standards work.
>
> Actually, what hasn't worked to date is an ad hoc process where people try to allocate identifiers
> as part of the language submitted for ballot. An identifier collision in a submitted proposal is what started
> this whole discussion. That's part of the reason I suggested moving to using GIT for the headers and also why
> I'm saying that this doesn't make sense to me.
>
> I don't really see how you can say it hasn't worked to date because we haven't done it. Also, this is in no way
> impacting the speed at which the TC moves. There have been items sitting for weeks (months?) waiting for review,
> discussion, and a vote -- none of that is becuase of identifier allocation.
>
>> We need to try out this approach and see how it goes.
>
> I am going to make the same argument -- we should try out the approach I suggested and see how it goes.
>
>> And what Valerie and Bob were asking for was feedback on the wording - not
>> going over the same argument that has already been discussed.
>
> This was only discussed off the main mailing list. Against my wishes, that discussion was not made public to date.
> No clear resolution was ever reached on that though, and my preference was, and has always been, that this be
> discussed with the TC as a whole for their input.
>
>> On 7 Jun 2016 12:50 pm, "Mark Joseph" <mark@p6r.com> wrote:
>>
>>>> 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.
>>
>> As far as the interoperability problem that is a different issue and one
>> that can be addressed by doing real interop testing just like the KMIP TC.
>> We are part of that KMIP TC and have gone though 3 intensive interop tests
>> of our product. It has been expensive yet very important to our
>> product and the KMIP standard. Now when I have a customer test our client
>> SDK against a KMIP server I am almost certain
>> they will work together. I am pretty sure that a lot of
>> our interoperability problems, including different constants, will go away
>> if we test properly
>> and publish the results.
>>
>>
>> Best,
>> Mark Joseph
>> P6R, Inc
>>
>>
>>
>> * From: * Chris Zimman <chris@wmpp.com>
>> * To: * Valerie Fenwick <valerie.fenwick@oracle.com>
>> * Cc: * <pkcs11@lists.oasis-open.org>
>> * Sent: * 6/6/2016 6:35 PM
>> * Subject: * [GRAYMAIL] Re: [pkcs11] Re: [pkcs11] Proposal: Standing Rule
>> for Identifier Allocation
>>
>>> On Mon, Jun 06, 2016 at 05:11:54PM -0700, Valerie Fenwick wrote:
>>> We have found from our experience with our last go round that
>>> waiting until just before the specification is ratified was too
>>> late.
>>
>> I'm not suggesting that anyone wait until just before the spec is ratified.
>> I'm saying something like the following:
>>
>> (1) Someone proposes an addition
>> (2) They write it up without an identifier
>> (3) They submit it to the TC
>> (4) The TC reviews and puts it to a ballot
>> (5) If it gets approved, it gets inserted into the draft and assigned an
>> identifier at that time
>>
>> This is a long time before anything moves towards official spec
>> ratification. Why would anyone add
>> something to an implementation before #5 though? What if it doesn't pass?
>>
>>> 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.
>>
>> Because, as Mark J. has also noted -- what happens to identifiers that
>> don't pass?
>> Why even make this problem at all?
>>
>> Also, why do chairs pick identifier numbers? That's an editorial (as in
>> those who maintain the docs and files)
>> function in my view. If the chairs want to also be editors though, that
>> can make sense I suppose.
>>
>>> 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.
>>
>> Assigning the number after the proposal passes ballot doesn't hold up what
>> you're saying here at all.
>> Adding something pre-ballot passing though, in my view, is done entirely at
>> your own risk.
>>
>> --Chris
>>
>>>
>>>> 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.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
> ---------------------------------------------------------------------
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]