Re: [ekmi] [Fwd: [ekmi-comment] Request for block of SKSML ErrorCodes for Vendor Use]

[Arshad Noor <arshad.noor@strongauth.com>]

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.
>>>
>>> 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/
>>
> 
> ---------------------------------------------------------------------
> 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