[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]
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. >> >> Subscribe: ekmi-comment-subscribe@lists.oasis-open.org >> Unsubscribe: ekmi-comment-unsubscribe@lists.oasis-open.org >> List help: ekmi-comment-help@lists.oasis-open.org >> List archive: http://lists.oasis-open.org/archives/ekmi-comment/ >> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> Committee: >> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi >> Join OASIS: http://www.oasis-open.org/join/ >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]