The group forced me to create the KCSLU
and KCDLU terms in order to describe the feature. In describing what
one device is doing, I could only talk about RAW because to read you need
to be in RAW mode and for the other when writing I could only talk about
EXTERNAL because you need to be in EXTERNAL to write. So I had to
narrow the discussion depending on whether I was talking about reading
or writing. The keyless copy section is intended to describe how to use
the RAW and EXTERNAL modes. I personally don't care what terms are
used. Let me describe the intent then we can understand what needs
to be described. Hopefully this will help us describe it clearly.
The intent is that a system can use
the keyless copy capability to copy data from one tape to another without
requiring an encryption/decryption key. The use case would be a data
recovery lab. The lab are the experts on getting the data off the
tape but the user doesn't want to expose the data. Hence the need
to copy the data without having the decryption key. I envision that
if a device supports RAW it will also support EXTERNAL. I really
don't see a use case where support for one but not the other makes sense.
I would have no problem with stating that if RAW is supported EXTERNAL
shall be supported and vice-versa.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt@us.ibm.com
http://www-03.ibm.com/servers/storage/
"Roger Cummings"
<roger_cummings@symantec.com>
06/20/2008 08:04 AM
To
Kevin D Butt/Tucson/IBM@IBMUS
cc
<t10@t10.org>
Subject
RE: SSC-3: Discussion related to Letter
Ballot SYM-019-a
Kevin,
I'm not sure that I can accept
your simplification that this collapses to which settings of "ENCRYPTION
MODE" and "DECRYPTION MODE" fields are supported. The issue
I'm having relates to the second paragraph on page 55 (PDF page 74) of
SSC-3 Rev 4a, which seems to imply that for some encryption algorithms
it's necessary for the KCSLU to support both EXTERNAL & RAW modes,
but for others RAW support is sufficient. Is the converse of this true
i.e. some LUs that support RAW mode will NOT be able to act as KCSLUs?
I do agree that this would be
a useful simplification if we can resolve the above point, which I freely
admit may be a misunderstanding on my point. And being able to read the
capability of an LU wrt encryption modes in advance would definitely be
a useful thing for our apps. But if we can make that simplification then
I'd recommend that we delete the terms KCSLU & KCDLU in their entirety
as all they mean is "an LU that supports RAW mode" and "an
LU that supports EXTERNAL mode" respectively.
Regards,
Roger
P.S. And I haven't forgotten that
I have an AI related to SYM-019-b, and I hope to have something on that
subject ready for Anchorage.
From: owner-t10@t10.org [mailto:owner-t10@t10.org]
On Behalf Of Kevin D Butt
Sent: Thursday, June 19, 2008 3:32 PM
To: t10@t10.org
Subject: SSC-3: Discussion related to Letter Ballot SYM-019-a
SYM-019-a:
The 4.2.21.5 Keyless copy section should identify How an application client
determines that a Logical Unit has the capability to act as a KCSLU or
a KCDLU
There is no bit anywhere that indicates the support for acting as a KCSLU
or KCDLU. In reality, it is if the LU supports the EXTERNAL encryption
mode or the RAW decryption mode. So the request here should be reworded
to say how does an application client determine which settings of "ENCRYPTION
MODE" and "DECRYPTION MODE" fields are supported.
Looking at the section describing each of these fields, there is no text
describing a CC returned for RAW or EXTERNAL if they are not supported.
The standard is silent. This is also the case for DISABLE.
Obviously the standard does not explicitly indicate anywhere
that these modes are optional.
What should we do?
Option 1: Add text under the description of these fields stating that if
EXTERNAL or RAW mode is selected and it is not supported then CC. This
would change the standard to explicitly state that these options are optional.
Option 2: Add text somewhere to mandate support for these modes. I
suspect this option is not desired.
I think that we must do either option 1 or option 2. The standard
needs to be clear if these are optional or not.
If we go done the path that these are explicitly stated as optional, then
this letter ballot comment leads to the question, "How do we report
support for different values in these two fields?" This is not
just a question of Keyless copy but also of MIXED decryption mode. There
is an implication that ENCRYPT and DECRYPT are supported as well as DISABLE.
I am not sure that is correct. There could be a device that
only supportes one or the other or some combinations.
Comments?
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt@us.ibm.com
http://www-03.ibm.com/servers/storage/