2 messages in org.oasis-open.lists.kmipRe: [kmip] Fw: Feedback on KMIP spec| From | Sent On | Attachments |
|---|---|---|
| Bruce Rich | Jan 26, 2010 1:00 pm | |
| Mary McRae | Jan 26, 2010 1:11 pm |
| Subject: | Re: [kmip] Fw: Feedback on KMIP spec | |
|---|---|---|
| From: | Mary McRae (mary...@oasis-open.org) | |
| Date: | Jan 26, 2010 1:11:37 pm | |
| List: | org.oasis-open.lists.kmip | |
Hi Bruce,
I'm not sure as to your question, but TC members must post their comments on
the regular tc e-mail list. The comment list is for use by those that are not TC
members.
Regards,
Mary
Mary P McRae Director, Standards Development Technical Committee Administrator OASIS: Advancing open standards for the information society email: mary...@oasis-open.org web: www.oasis-open.org twitter: @fiberartisan #oasisopen phone: 1.603.232.9090
Standards are like parachutes: they work best when they're open.
On Jan 26, 2010, at 4:00 PM, Bruce Rich wrote:
Someone (me) apparently didn't get the memo about TC members cc'ing the rest of
the TC on their appends to the public comment list.
My apologies to those of you who aren't subscribed to the kmip-comment list.
Bruce A Rich brich at-sign us dot ibm dot com
----- Forwarded by Bruce Rich/Austin/IBM on 01/26/2010 02:57 PM ----- From: Bruce Rich/Austin/IBM To: kmip...@lists.oasis-open.org Cc: bri...@us.ibm.com Date: 01/14/2010 10:17 AM Subject: Feedback on KMIP spec
I have the following issues with the KMIP specification.
Section 4.24
Given that the operations required to be supported have been delegated to the
profile, all operations (save Query) are now theoretically optional, so the
Query Operations response must be able to report all operations, not just the
formerly optional operations of Validate, Certify, Re-Certify, Notify and Put.
Additionally, it would be useful to have Query report on which profiles are
supported, as this would provide clients a quick way to determine the minimum
set of operations supported by the server.
Section 11.21
The server will return an error result/reason of
OperationFailed/PermissionDenied if a destroy() is requested and the object is
not already deactivated. Failing destroy() seems an appropriate response if the
object were ACTIVE, but not if it were PREACTIVE. So the request is to change
the language to say "Object is not in a state of PREACTIVE or DEACTIVATED". One
might also argue that a new reason of IllegalStateTransition would be more
meaningful than PermissionDenied, but that might require a more intrusive set of
changes, so would recommend against that new reason.
Table 45
The Cryptographic Domain Parameters table (Table 45) lists an enumeration for
the Recommended Curve, but no reference is given for said enumeration. It might
be 9.1.3.2.5, but I'm guessing.
Bruce A Rich brich at-sign us dot ibm dot com