OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ekmi message

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