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] KMIP operations and objects: addition of Version to Server Information response


Hi Robert,
 
Compliance profiles may convey that type of information, but I was thinking of something simpler - perhaps just a "Major:Minor:Revision" version that reflected the basic minimums required of the standard (e.g., "1:00:B").
 
Regards,
Rod
 


From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, June 25, 2009 8:26 AM
To: Rod Wideman
Cc: kmip@lists.oasis-open.org
Subject: RE: [kmip] KMIP operations and objects: addition of Version to Server Information response


Rod,
From your description  of a "Version Indicator" (in the Server Information that can be queried by clients), it looks more like a list of compliance profiles that the server would support or? I assume we will eventually have such a mechanism.
Thanks,
-Robert

"Rod Wideman" <Rod.Wideman@quantum.com> wrote on 06/10/2009 04:40:03 PM:

>
> 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:brich@us.ibm.com]
> Sent: Wednesday, June 03, 2009 5:44 PM
> To: kmip@lists.oasis-open.org
> 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.


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