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 ServerInformation response
- From: Robert Haas <rha@zurich.ibm.com>
- To: "Rod Wideman" <Rod.Wideman@quantum.com>
- Date: Thu, 25 Jun 2009 15:25:59 +0200
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]