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: Interoperable Key Naming for Tape - v3


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-----
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  


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