[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi] [Fwd: [ekmi-comment] Request for block of SKSML ErrorCodes for Vendor Use]
Not a problem, Anil; we can discuss this on Friday. Arshad Anil Saldhana wrote: > I have no issues with the standard error codes and messages. In fact, I > support standard error codes. > > What I am uncomfortable is that SKMS-ERR-111111 is an error generated by > company A implementation because the code falls in the range allocated > to company A. :) Maybe because I have never seen this in any of the > standards that I have dealt with, that I am feeling a bit uncomfortable. > > I would probably like to discuss this at the next TC meeting such that I > can be educated about the importance of these vendor blocks of error codes. > > Arshad Noor wrote: >> Just wanted to add one other clarification, Anil: >> >> Vendors only have to implement the protocol within 6-12 months >> of requesting the block of codes. Obviously, they can choose >> to wait as long as they want to make the request for the codes. >> >> The reason we came up with the time limit was because it was >> agreed that we shouldn't let vendors reserve a block of codes >> and then take forever to implement the protocol (or never >> implement it at all); the TC wanted to retain the right of >> taking back the block of codes from the non-conformant vendor >> if it chose to. >> >> Arshad >> >> Arshad Noor wrote: >>> Hi Anil, >>> >>> This was discussed in a thread on the list, back in September 2008; >>> there are about 4 messages on the list archives after I'd proposed >>> the format and methodology in the DRAFT Specification: >>> >>> http://lists.oasis-open.org/archives/ekmi/200809/msg00009.html >>> >>> The benefit is most useful to large companies that may begin with a >>> single SKMS, but over time merge with or acquire another company, or >>> be acquired by another company with another vendor's SKMS. If there >>> were no standards on error-codes/messages, you'd have two different >>> SKMSs providing completely different types of error codes/messages >>> for the same types of errors. >>> >>> Given that most companies will consolidate the operations and >>> maintenance of SKMSs within the same group, we will only increase >>> the TCO of the company if we don't standardize some codes/messages. >>> >>> What we've agreed to do in the spec is that some of the most common >>> codes/messages will be standardized, while leaving vendors the option >>> to get a unique block of codes from the TC to implement codes/messages >>> for proprietary features. >>> >>> I strongly believe that SysAdmins and SecurityAdmins will appreciate >>> the consistency in standard codes/messages, no matter which vendor >>> supplies the SKSML implementation. >>> >>> I realize that no OASIS TC has gone where we are going; but then >>> again, we are one of the few TCs that has the advantage of having a >>> very diverse set of TC members - people from operations, security, >>> audit, protocol implementers, business-application developers, etc. >>> So, I'm not surprised at all that we're doing things differently >>> (better, IMO :-)). >>> >>> Arshad >>> >>> P.S. I also don't think the management of these codes and procedures >>> is that onerous, Anil. I already setup some pages on the wiki for us >>> to manage, with StrongAuth's request already up on the wiki: >>> >>> http://wiki.oasis-open.org/ekmi/RequestsForVendorCodeBlocks >>> >>> Anil Saldhana wrote: >>>> I am not sure whether vendors choosing a block of codes will improve >>>> interoperability. I also do not know when this appendix D, Section >>>> 4 was discussed in the TC. I have serious objection to vendors >>>> making statements that they will implement the specification within >>>> 6-12 months and also have objections to the TC doing additional work >>>> in maintenance of vendor requests to error codes. >>>> >>>> * I am not aware of any other specification taking this route - >>>> where vendors have to request blocks of error codes and have to make >>>> assertions that they will implement in 6-12 months. >>>> >>>> Please appraise me of how blocks of error codes assigned to vendors >>>> will improve interoperability. >>>> >>>> Arshad Noor wrote: >>>>> Not sure how many of you are on the >>>>> ekmi-comments@lists.oasis-open.org, >>>>> but I thought I'd forward this to the TC list so everyone is aware of >>>>> our request. >>>>> >>>>> Since I'm setting myself up to be the guinea-pig for this process, I >>>>> will work with Anil on creating a page on the EKMI Wiki to track this >>>>> request. I'll also setup a ballot for a vote on this request. >>>>> >>>>> Thanks. >>>>> >>>>> Arshad >>>>> >>>>> -------- Original Message -------- >>>>> Subject: [ekmi-comment] Request for block of SKSML Error Codes for >>>>> Vendor Use >>>>> Date: Tue, 13 Jan 2009 15:33:34 -0800 >>>>> From: Arshad Noor <arshad.noor@strongauth.com> >>>>> Organization: StrongAuth, Inc. >>>>> To: ekmi-comment@lists.oasis-open.org >>>>> >>>>> In accordance with Appendix D of the DRAFT SKSML 1.0 Specification >>>>> PR02, we would like to request a block of SKSML codes for use by >>>>> StrongAuth, Inc. >>>>> >>>>> We assert the following: >>>>> >>>>> 1) We will implement the SKSML 1.0 specification within 6-12 months >>>>> of the date of this request; >>>>> >>>>> 2) We will implement ALL the Standard Codes & Messages as described >>>>> in the SKSML Specification; >>>>> >>>>> 3) We will not duplicate any Standard Code or message within our >>>>> assigned private vendor block of numbers; >>>>> >>>>> 4) If the TC later chooses to standardize a specific message within >>>>> the Standard Codes, which may overlap with our assigned private- >>>>> block message, we will use the Standard Code in the implementations >>>>> created subsequent to the standardization of the code/message; >>>>> >>>>> 5) We will notify the EKMI Technical Committee of the release date of >>>>> our product, highlighting the relevant section of our documentation >>>>> using the Standard Codes and Messages, upon the release of the >>>>> product. >>>>> >>>>> Thank you >>>>> >>>>> Arshad Noor - (Authorized representative) >>>>> CTO >>>>> StrongAuth, Inc. >>>>> (408) 331-2000 >>>>> >>>>> -- >>>>> This publicly archived list offers a means to provide input to the >>>>> OASIS Enterprise Key Management Infrastructure (EKMI) TC. >>>>> >>>>> In order to verify user consent to the Feedback License terms and >>>>> to minimize spam in the list archive, subscription is required >>>>> before posting. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]