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