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
- From: "Rod Wideman" <Rod.Wideman@quantum.com>
- To: "Robert Haas" <rha@zurich.ibm.com>
- Date: Thu, 25 Jun 2009 08:50:17 -0600
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
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]