[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]
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]