Re: [kmip] Fw: Feedback on KMIP spec

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:  

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:


Cc:


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