SSC-3: Discussion related to Letter Ballot SYM-019-a

Kevin D Butt kdbutt at
Fri Jun 20 11:14:12 PDT 2008

Formatted message: <A HREF="r0806204_f.htm">HTML-formatted message</A>

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.
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 at 
"Roger Cummings" <roger_cummings at> 
06/20/2008 08:04 AM
Kevin D Butt/Tucson/IBM at IBMUS
<t10 at>
RE: SSC-3: Discussion related to Letter Ballot SYM-019-a
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.
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 at [mailto:owner-t10 at] On Behalf Of Kevin D 
Sent: Thursday, June 19, 2008 3:32 PM
To: t10 at
Subject: SSC-3: Discussion related to Letter Ballot SYM-019-a
The 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 
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 
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. 
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 at 

More information about the T10 mailing list