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] RE: Point of clarification on OASIS process


Hi Mary,

Thank you for taking the time to respond in detail. I think many of us
appreciate the desire to allow competing standards to ensure that the
public is given the best possible choices. However, where I think I
disagree with you is in the particulars of the charter process here.
Specifically, the way you've explained things, and the way that the KMIP
charter has been launched, suggests that OASIS is, wittingly or not,
enabling gamesmanship on the part of a vendor who does not seem to be
acting in good faith.

In point of fact, the convener of the KMIP TC is an observer of the EKMI
TC, as well as a believed member of the IEEE P1619.3 committee that is
also developing a key management standard. Due to the observer status,
this individual is not allowed to participate in the EKMI TC, which I
think is where we have an interesting dilemma. Rather than become a
member of and express their viewpoint in the EKMI TC, they've instead
splintered off without performing due diligence to create a competing
standard.

It's this last point of due diligence where I am particularly concerned,
and where I hope you and the OASIS board might look to make changes
going forward. Any proposed technical committee should be required to
first evaluate existing committees to determine whether or not overlap,
or congruency, will exist with their proposed charter. In the case where
there is apparent overlap or congruency, the proposers should be
required to engage an existing committee to first evaluate the
opportunity to contribute to the existing project in the way they
desire, and to allow the convened TC an opportunity to identify new
prospective members and perspectives that may not have been otherwise
considered. This lack of requirement for due diligence actually
undermines the work of both the convened and proposed committees by
creating a line of exclusivity that prohibits optimal creativity and
development.

In this specific case, there is reason to believe that RSA/EMC has ideas
congruent with the work of the EKMI TC that they'd like to see
developed. It would have been highly appropriate for them, as observers
of the EKMI TC, to discuss those ideas in some venue with the EKMI TC
before launching their own competing TC. If the OASIS rules do not allow
an observer to enter into these discussions, then the rules need to be
changed. Where you've claimed an opportunity for open competition, we
see a case of the development process being undermined. An observing
member of the TC, rather than contributing to the TC, has opted to form
a competing TC with what appears to be considerable overlap and
congruency. This should be a cause for concern to OASIS.

OASIS, by it's own description, exists to drive "the development,
convergence and adoption of open standards for the global information
society." Yet in this case, by not requiring or permitting the
performance of due diligence, OASIS is actually working against
convergence within the key management space, creating division and
discord where there could, and probably should, be cooperation and
collaboration. This event seems to work completely contrary to the
objective of OASIS.

It's unclear at this point if there is any way to address these concerns
between EKMI and KMIP, but it would be highly valuable to convene a
joint call between the KMIP proposers and the EKMI TC to see if there
really is a reason for the two separate TCs to exist. If this is not
possible, particularly due to OASIS rules, then it would be my sincere
hope that the OASIS board would perform a critical review of this
situation with an eye toward making improvements so that similar
situations do not arise in the future. Convergence cannot occur if
conversations cannot be held.

Thank you,

-ben

-- 
Benjamin Tomhave, MS, CISSP
falcon@secureconsulting.net
LI: http://www.linkedin.com/in/btomhave
Blog: http://www.secureconsulting.net/
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/

[ Random Quote: ]
"We cannot despair of humanity, since we ourselves are human beings."
Albert Einstein

Mary McRae wrote:
> Hi Arshad,
> 
>   Let me respond as the OASIS TC Administrator - my responsibilities include
> overseeing all aspects of the TC Process and making sure it is adhered to. 
> 
> It appears that the KMIP co-proposer group is very much aware of the
> existence of the EKMI TC and have referenced its work in their proposed
> charter. 
> 
>   There is no OASIS policy prohibiting one TC from working in a similar area
> to another; if that were the case we would not have both DocBook and DITA
> TCs - while I can certainly differentiate between the two, many can't, and
> both groups would argue that you don't really need the other. There are
> similar examples in many other functional areas.  By permitting multiple
> projects to grow in parallel, OASIS now has fostered several viable
> technologies, which have differentiated over time, each with its own niche.
> Implementers often choose to use them in combinations the proposers might
> not have expected.
> 
>   A TC does not have veto rights over the creation of a new TC; in fact, as
> long as the requisite number of co-proposers meeting our requirements put
> forth a valid proposal it is accepted. I encourage the members to submit
> comments on the proposed charter and anticipate that the co-proposers are
> anxious to respond.
> 
> Best regards,
> 
> Mary
> 
>> -----Original Message-----
>> From: Arshad Noor [mailto:arshad.noor@strongauth.com]
>> Sent: Tuesday, February 17, 2009 3:01 PM
>> To: 'James Bryce Clark'; Mary McRae; Dee Schur
>> Cc: Robin Cover; ekmi; laurent liscia
>> Subject: Point of clarification on OASIS process
>>
>> Jamie/Mary/Dee,
>>
>> As Robin may have indicated to you all, there is near unanimous
>> consensus in the EKMI TC (one member withheld his opinion because
>> he hadn't read the KMIP TC charter yet) that the KMIP TC charter
>> overlaps the EKMI TC's charter (the meeting notes should be out
>> as soon as Anil posts them).
>>
>> While OASIS process may allow the release of any new TC's charter
>> for discussion, the EKMI TC is, obviously, disappointed that this
>> new charter was released without any discussion with the EKMI TC
>> before-hand, to avoid potential embarrassment to EKMI TC members
>> and OASIS in the public arena.  After all, OASIS EKMI TC members
>> have only been working on this for 2+ years with laser-like vision
>> and focus and reached Committee Specification status, while the
>> IEEE effort has been floundering for lack of vision and the IETF
>> work is reviewing its own focus as it starts to overlap with the
>> EKMI work (they are even incorporating some SKSML concepts into
>> their own schema now).
>>
>> Now that the cat is out of the bag, the TC is interested in
>> understanding OASIS policy/process wrt duplicate/overlapping
>> charters of an existing TC and a potential new TC.  What is
>> legally possible now?
>>
>> Do OASIS rules permit the creation of the KMIP TC despite the
>> near-unanimous consensus amongst EKMI TC members that the KMIP
>> TC charter overlaps the EKMI TC's?
>>
>> Your answers will help the EKMI TC in understand what its options
>> are.
>>
>> Thank you.
>>
>> Arshad Noor
>> StrongAuth, Inc.
> 
> 
> ---------------------------------------------------------------------
> 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 
> 
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]