OASIS Key Management Interoperability Protocol (KMIP) TC

The document revision named Interoperable Key Naming for Tape - v3
(Interoperable Key Naming - v3.doc) has been submitted by Mr. Stan Feather
to the OASIS Key Management Interoperability Protocol (KMIP) TC document
repository.  This document is revision #2 of Interoperable Key Naming.doc.

Document Description:
This adds a section to the KMIP User's Guide, providing a common method of
storing key names on KMIP servers.  This supports moving encrypted media
between multi-vendor solutions.

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=33748

Download Document:  
http://www.oasis-open.org/committees/download.php/33748/Interoperable%20Key%20Naming%20-%20v3.doc

Revision:
This document is revision #2 of Interoperable Key Naming.doc.  The document
details page referenced above will show the complete revision history.


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration

I chatted with Stan on this proposal, and have concerns with how it ties into name spaces.

While the primary context for this proposal is for multi-vendor tape library clients connected to a KMIP server, and it solves that problem nicely, it is forever linking the LTO4 name space to this implied behavior (more on this later from the namespace perspective).  The proposal contains acceptable constraints with how libraries deal with the SCSI unauthenticated v. authenticated KAD fields, though other solutions which could benefit from the LTO4 namespace may find it difficult to adhere to these constraints.  The solution may be two namespaces, though if the case,  I'd like to see the LTO4-LIBRARY used for this purpose and LTO4 reserved a more general purpose behavior.  

Now back to the namespaces.
The Application Specific Information proposal states "... results in the server returning a suitable Application Data value provide the server is able to generate Application Data for this particular Application Name Space.".  Additionally it states "The Usage Guide provides a list of application name spaces".

It will be problematic to have normative behavior governed by a Usage Guide name space definition.   
I believe KMIP must address the tape library needs, but it needs to fit within the long term plan for name spaces.  

I'll be out of the office much of next week and unable to attend the weekly call.  I'll follow up upon return.

Regards,

Tom  

I've modified the Interoperable Key Naming for Tape document to use the LIBRARY-LTO4 namespace, as Tom suggests. 

But I think the primary concern raised in Tom's email, and by several others, regards the requirements for supporting the namespaces.  Presently these requirements are being placed in the Application Specific Information section in the Usage Guide, which is a concern for several reasons.  An alternative is to move these requirements from the usage guide to the spec.  That may also be problematic, if we find many namespaces, and/or namespace requirements become granular. 

A longer term alternative may be to establish a public registry of the namespaces.  The spec isn't cluttered with application-specific detail, and the usage guide remains informative.  The registry can ensure uniqueness, as well as correlating requirements for supporting the namespace.   This is something I'd planned to propose in our KMIP 2.0 discussions.

However, the first priority is a short term solution.  Perhaps we can discuss some of the options tomorrow.

Stan
 





                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Thomas Clifford [mailto:thomas_clifford@symantec.com] 
Sent: Friday, August 14, 2009 12:02 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] Interoperable Key Naming for Tape - v3

I chatted with Stan on this proposal, and have concerns with how it ties into name spaces.

While the primary context for this proposal is for multi-vendor tape library clients connected to a KMIP server, and it solves that problem nicely, it is forever linking the LTO4 name space to this implied behavior (more on this later from the namespace perspective).  The proposal contains acceptable constraints with how libraries deal with the SCSI unauthenticated v. authenticated KAD fields, though other solutions which could benefit from the LTO4 namespace may find it difficult to adhere to these constraints.  The solution may be two namespaces, though if the case,  I'd like to see the LTO4-LIBRARY used for this purpose and LTO4 reserved a more general purpose behavior.  

Now back to the namespaces.
The Application Specific Information proposal states "... results in the server returning a suitable Application Data value provide the server is able to generate Application Data for this particular Application Name Space.".  Additionally it states "The Usage Guide provides a list of application name spaces".

It will be problematic to have normative behavior governed by a Usage Guide name space definition.   
I believe KMIP must address the tape library needs, but it needs to fit within the long term plan for name spaces.  

I'll be out of the office much of next week and unable to attend the weekly call.  I'll follow up upon return.

Regards,

Tom