[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Re: [GRAYMAIL] 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]