Kevin,
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?
Regards,
Roger
Roger,
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/