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: RE: [kmip] Issue with KMIP SoUs/conformance vs. Use Cases


hi Mary, Steve -

Both KMIP Use Cases and KMIP Usage Guide are indeed only illustrative,
not normative. Although it would be great to have everything in the
profiles fully elaborated in KMIP Use Cases, I agree that this not
required.

We'll discuss the question of whether to keep them at Committee
Specification, rather than requesting that they be voted to OASIS
Standard, in our KMIP TC call this morning.

regards,

Bob

-----Original Message-----
From: Mary McRae [mailto:mary.mcrae@oasis-open.org] 
Sent: Thursday, June 03, 2010 10:05 AM
To: Wierenga, Steven
Cc: Griffin, Robert; kmip@lists.oasis-open.org
Subject: Re: [kmip] Issue with KMIP SoUs/conformance vs. Use Cases

Disclaimer: This is just a question, and not any sort of TC
Administration judgement, but:

Are the Use Cases and Usage Guide really intended to become a standard?
Do they contain normative material that isn't in either the base spec or
the profiles document? Isn't the Use Cases document a set of possibles,
but not onlys (I think I just made up a word)? Both the Use Cases
document and the Usage guide state that there are no conformance clauses
associated with either. I would suggest that the UC and UG hold at the
level of CS; it does not diminish their importance, and they can still
be referenced by the main spec and profiles doc.

Regards,

Mary



On Jun 3, 2010, at 2:53 AM, Wierenga, Steven wrote:

> Hello Bob and all,
> 
> While doing due diligence preparing the HP Statement of Use, I noticed
some discrepancies between the Profiles document and the Use Cases which
make it problematic to claim or corroborate conformance and interop
based on the Use Cases:
> 
> 1. The Secret Data Profile requires - Enumerated Objects - Key Format
Type - Opaque.  However there is no instance of Opaque in the Use Cases
document.
> 
> 2. The Basic Symmetric Key Store and Server Profile requires -
Enumerated Objects - Key Format Type - Transparent Symmetric Key.
However there is no instance of Transparent Symmetric Key in the Use
Cases document. 
> 
> 3.  Likewise, the Basic Symmetric Key Foundry and Server Profile
requires - Enumerated Objects - Key Format Type - Transparent Symmetric
Key.  Again, there is no instance of Transparent Symmetric Key in the
Use Cases document. 
> 
> This is not just an editorial issue, if conformance/interop have not
been fully verified or are not verifiable under the current Use Cases.
Either the Profiles or the Use Cases need to be amended to match.
> 
> Thanks,
> --Steve Wierenga
> HP
> 
> ---------------------------------------------------------------------
> 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]