KMIP operations and objects

I like the idea of the standard specifying a 'minimum' or 
basic set of compliance points.  It would be convenient if there was a 
single table that listed all the client to server operations and indicated each 
as being either 'mandatory' or 'optional', with 'mandatory' being with respect 
to the minimal compliance point. And also a table that similarly listed all the 
managed objects.
 
However I think that a Version indicator for the standard 
should be added to the Server Information response structure to a Query 
request.  Currently the Server Information field is a structure containing 
vendor specific fields, so adding a required field to indicate the version of 
the standard to which the server complies would be fairly simple.  There is 
of course the Protocol Version field in the message header, but that reflects 
things at the message level and may change independently from compliance at the 
object/operation level.
 
So I think there's the opportunity for three proposals 
against the draft standard:
 - table of managed objects indicating 
mandatory/optional
 - table of client to server operations indicating 
mandatory/optional
 - addition of Version to Server Information 
response
 
Within the framework of these proposals, the discussion 
could continue as to what constitutes mandatory vs. 
optional.
 
thanks,
Rod Wideman
Quantum Corporation
(please disregard the confidentiality statement 
below)
 



From: Bruce Rich [mailto:]
Sent: Wednesday, June 03, 2009 5:44 PM
To: 

Subject: [kmip] KMIP operations and 
objects



Before we close down discussion of modifications to KMIP 
v1 and given the fact that the compliance discussion for KMIP is lagging a bit, 
I would like to enter the following proposal:

If we were to move the following objects to 
optional
        
SecretData
        
OpaqueObject
and the following 
operations to optional
    
    DeriveKey
    
    Archive
    
    Recover
    
    Get with WrappingSpecification
then we more or less have in place what was deemed adequate for the proof 
of concept (POC) implementations.

Then complying with this newly-coined, limited set of required objects 
and operations could be more or less a "Basic Profile".

Complying with the full set of required and optional 
objects and operations could be an "Advanced Profile".  (And there may be 
several steps between basic and advanced, but I am most interested in "Basic", 
at least for now.)

(NB. 
 Archive and Recover were part of the POC, but are adding states outside of 
those defined in the NIST state model, and it may be useful to be able to 
exclude those from an entry-level model)
(NB. Given transport security, one can argue that the 
WrappingSpecifications are not absolutely necessary for an entry-level 
model)
(NB,  Strictly speaking, ALL 
of the KMIP objects seem to be optional, since the Query Objects response need 
not have any objects listed, but I wanted to emphasize that a very useable 
first-step KMIP implementation could be had without supporting SecretData and 
OpaqueObject)

I apologize if this is 
viewed as overly controversial, but I'm reluctant to end discussion about KMIP 
v1 content without some closure on the compliance/profile discussion.

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

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.