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

Roger Cummings roger_cummings at
Mon Jun 23 12:40:26 PDT 2008

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

OK let's see if this simplification will stick: Does anyone on this list
have an issue with amending SSC-3 Rev 4a to state that if one of RAW &
EXTERNAL is supported, then the other SHALL be supported? 
I also understand the use case that you describe below, and that's not
where my concerns lie. We keep talking about keyless copy as if it's
always a 1-to-1 situation, but in fact I don't think there's any way we
can mandate that: There's nothing to prevent an application from reading
an entire tape in RAW mode, storing that "image" away, and then shipping
the image and the required KAD around the world and creating four copies
of the tape in four different places. I'm not convinced the requirements
listed in the aforementioned second paragraph on page 55 (PDF page 74)
of SSC-3 Rev 4a adequately cover that case. For instance, do source and
destination drive have to support the encryption algorithm used to
create the original tape ONLY if the KAD has to be compared? Do we need
to separately cover the cases where either the KCSLU & KCDLU do NOT
support that algorithm?
	From: Kevin D Butt [mailto:kdbutt at] 
	Sent: Friday, June 20, 2008 2:14 PM
	To: Roger Cummings
	Cc: t10 at
	Subject: RE: SSC-3: Discussion related to Letter Ballot
	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
	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"
	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
	From: owner-t10 at [mailto:owner-t10 at] On Behalf Of
Kevin D Butt
	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
	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. 
	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