RE: [kmip] RE: question regarding conformance statement for KMIP

["Rod Wideman" <Rod.Wideman@quantum.com>]

I like the use of tables to indicate what objects and operations are mandatory or optional.  I'd prefer to see them in the respective clauses on objects and operations (e.g., at the beginning of the clause, and the table itself can include a link to the subclause from the row for the item, so it serves as a mini TOC also).

 

But I think that the KMIP Standard (and not the Usage Guide) should be the sole keeper of the compliance definition (with respect to support of objects and operations).  How to reference KMIP, etc, seems fine in the Usage Guide.

 

thanks,

Rod Wideman

Quantum Corporation

(please disregard the confidentiality statement below)

 

---

From: Robert Lockhart [mailto:Robert.Lockhart@thalesesec.com]
Sent: Saturday, May 16, 2009 12:09 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] RE: question regarding conformance statement for KMIP

I agree there should be additions to the conformance section.  I have included several proposed changes (as requested a few meetings ago) as a place to start.  They include conformance claims, a table of required vs. optional items for both client and server (to be filled in), reference guidelines when claiming conformance by another standard and usage guidelines when using KMIP without claiming conformance.

 

http://www.oasis-open.org/apps/org/workgroup/kmip/download.php/32554/Conformance_Clause_Proposal.doc

 

Not sure if this is what you were looking for from me Bob & Tony when you asked but this is what I have so far.  Looking for feedback.

 

Bob L.

 

Robert A. (Bob) Lockhart

Senior Solutions Architect

THALES Information Systems Security

 

-------------------------------------------------------

T:      +1 408 457 7711 (Direct)

M:     +1 510 410 0585

F:      +1 408 457 7681

E:      rlockhart@ncipher.com

W:     www.nCipher.com

 

         nCipher product line. See www.nCipher.com

---

From: robert.griffin@rsa.com [robert.griffin@rsa.com]
Sent: Wednesday, May 13, 2009 5:35 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] question regarding conformance statement for KMIP

Hi -

Rather than convening a meeting on conformance (as I'd suggested a
couple of meetings ago), I'd like to pose the question I've been
wondering about and see if there is an issue or not:

-       Should we modify the language in Section 5 of the Usage Guide to
clarify what "support all objects etc" means? In particular, do we need
to clarify whether this means a) the server has to implement all
mandatory objects etc or b) the server has to understand requests
related to all mandatory objects etc (but can return back an "object not
supported" message).

In drafting the conformance language currently included in the Usage
Guide, I followed the advice expressed in the Conformance Testing
document available at http://xml.coverpages.org/conform20000112.html:
that is, "the requirements or criteria for conformance must be specified
in the standard or specification. This is usually in a conformance
clause or conformance statement..."

The conformance statement in section 5 of the KMIP Usage Guide
distinguishes between conformance requirements for KMIP servers and
clients:

"Server implementations of the KMIP protocol must support all objects,
attributes, operations and profiles not specified as "optional" in the
KMIP Specification in order to be conformant to the specification.
Server implementations that do not support objects, attributes,
operations and profiles defined as "optional" can claim KMIP
conformance, though they may be limited in terms of interoperability
with other KMIP implementations.

Client implementations of the KMIP protocol may implement any subset of
the KMIP protocol. For example, a client may implement only the Get and
Locate operations for symmetric keys. In order to claim conformance,
however, such a client must implement all aspects of any elements of the
protocol (objects, attributes, operations, profiles) that it claims to
support. In the example of Get/Locate support for symmetric keys,
therefore, a conforming client implementation must support all required
attributes for symmetric keys."

In re-reading the conformance statement for server implementations, it
looks to me that I made it more restrictive than I intended - that the
language should perhaps have been something like:

"Server implementations of the KMIP protocol shall accept and respond to
client requests for all objects, operations and profiles not specified
as 'optional' in the KMIP Specification in order to be conformant to the
specification; a conformant response can be 'this object etc is not
supported.'"

But perhaps it's better to have the more restrictive language, after
all?

I'd appreciate your thoughts!

Regards,

Bob

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +1 (781) 994 4000 or email ussales@ncipher.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of nCipher Inc.

---

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.