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

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

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


Subject: proposal for EXPERIMENTAL in KMIP standards


Hello all,
 
  As KMIP is evolving, it is also getting bigger in scope and targeting various interesting markets. However, there is still a large set of issues that the customers seeks and vendors are willing to provide. Using KMIP, the vendors can roll-out those features/capabilities/workflows as vendor-extensions. For a relatively small and rare use case or a niche market that is not very sizeable, this definitely helps. There are certain markets that are growing rapidly and as we work on our cadence (yearly) we may not be able to address and incorporate such requirements in realistic time for their market adoption. In the interest of time, strong players in those emerging markets typically choose to define proprietary mechanisms, sometimes in collaboration with key management vendors. As the KMIP TC had much wider composition of  participants from companies  representing various technology domains, it is possible for us to have a discussion about provide a recipe for such use cases. As those use cases are evolving, we can mark them experimental until they mature and/or have wider participation of companies working on them directly. Now, this is forward-looking usage of KMIP. To illustrate, we can cite cloud use cases with v1.1, big data etc.

 There is also the legacy stuff and the ongoing improvements that we often see in the key management space that is currently being packaged as vendor-specific extensions of KMIP. Many parts of these extensions have been discussed within the KMIP TC and we either agree to defer folding them into standard to a later version Or agree to disagree as there is no unanimous consensus about the same (for the lack of time, investigation or participant commitment) which again leads to deferring it to a later version. Those parts of the extensions that have been discussed can be considered to be listed as experimental in the standard.

 I would like to thank the TC members who I had the opportunity to discuss this with before making the proposal and create this short list of questions that will explain the proposal better -

1. Is Experimental new to standards?
A.  No. RFCs and other standards are known to have EXPERIMENTAL.

2. How does it help industry perception for the KMIP standard?
A. The industry will understand that the KMIP is definitely considering these use-cases and in the course of time, will address them in the main standard. More mind share is good.

3. How does it affect interop?
A. Experimental is purely optional for those who would like to implement. There is no interop requirement to meet the standard however key management vendors who would like to pursue the use cases described in experimental are recommended to do some interop and bring out the issues for improving the use cases in the next version.

4. How does something make into Experimental?
A. The same procedure that we follow for the KMIP standard applies here. The only difference here is that we do not endorse or standby the quality or completeness of the work published as experimental. And, the vendors do not have the obligation to perform interop.

5. What aspects of the KMIP standard is this limited to?
A. Initially, we can narrow it down to just [a] Use Cases/User stories [b] Vendor extensions

Please send me your comments/opinions/feedback.

Thanks,
Kiran


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