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] 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.



Mary P McRae
Director, Standards Development
Technical Committee Administrator
OASIS: Advancing open standards for the information society
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-comment@lists.oasis-open.org
Cc: brich@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, but I'm guessing.

Bruce A Rich
brich at-sign us dot ibm dot com

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