Comments on 05-446r9

[Paul Entzel]

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

Kevin,
Thanks for your comments.  I have included responses below to the
technical comments so you have a chance to think them over before we
discuss them at tomorrow's conference call.
Paul Entzel
Quantum
-----Original Message-----
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Tuesday, March 21, 2006 4:01 PM
To: Paul Entzel; T10 at t10.org
Subject: Comments on 05-446r9
Paul and all, 
I have some comments on 05-446r9 
TECHNICAL: 
1) Section 4.2.9.13, pg 6, last sentence of 2nd to last paragraph, "The
device server shall establish the logical position at the BOP side the
encrypted block." should be "The device server shall establish the
logical position after the failed encrypted block."  This will make the
behavior consistent with reading a corrupted block. 
[Paul Entzel] I disagree for two reasons:
1.	This will add an extra step to the recovery process.  The
expected recovery for this type of error is to send a SPIN command
requesting the Next Block Encryption Status page, send a SPOUT command
with a Set Data Encryption page configuring the encryption accordingly,
and the re-issue the read.  If the tape is positioned behind the block
in error it will add another command to this recovery process to
re-position in front of the block first.
2.	The Sense Key used to report the error is DATA PROTECT.  Not
change the logical position when reporting this error is consistent with
other conditions that use this Sense Key.
2) Section 4.2.19.5, pg 8.  All the statements about establishing a UA
for all other I_T Nexus that are affected by.... 
If this is the behavior that we take, then this will severely inhibit
being able to use a third party device - like a Decru EKM transparent to
the application.  The UA's will cause the applications or host on which
the applications reside, to handle these UA's that it knows nothing
about. 
[Paul Entzel] I have never been a big fan of UAs.  As a developer of
SCSI devices I have always found them to be a complete pain in the rear.
They're difficult to deal with when protocol bridges are used.	They get
eaten by the driver stack on the host side.  Yuck.  However, this is how
we manage asynchronous event reporting in SCSI.  This will be an
interesting discussion topic tomorrow.
I think the UA's should be restricted to those I_T Nexus over which a
Security Protocol Out/In command has been received and not to any body
else.  This will allow using an External EKM transparent to
applications. 
[Paul Entzel] Interesting idea you have there.	It will need to be
developed a bit more before it will work, but it has potential.  I
interpret your idea as adding a Boolean variable to the per I_T Nexus
database defined in subclause 4.2.19.6 that indicates if a SPIN or SPOUT
command has been executed from the I_T Nexus.  Only I_T Nexus that have
this variable set to True would get UAs associated with encryption.  I
have two questions:
1.	When does it get set to False (resets, I_T Nexus loss,
de-mount)?
2.	How do we document this precedence setting feature?
3) Section 4.2.19.6, pg 8, second list. Should a "Prohibit Encryption"
be added? 
[Paul Entzel] Not necessarily.	If the SCOPE field is set to PUBLIC then
control of data encryption for that I_T Nexus is passed to other
initiators and may or may not be enabled.
4) Section 4.2.19.7, pg 9.  Please add "CKORSC" to list. 
[Paul Entzel] Agreed.
5) Section 4.2.19.7, pg 9.  Item c) of list - key scope.  I was confused
here and it took me some time to realize that "key scope" is referring
to a value in Table Y2 for the "scope" field of the set data encryption
page.  Please add a definition and/or cross reference for this term. 
[Paul Entzel] Everything in this structure comes from fields in the Set
Data Encryption page or from knowledge the device server has about the
I_T Nexus that sent the Set Data Encryption page.  Of course, I supposed
it is possible to use an out-of-band method for establishing the data
encryption parameters (see comment 6).
6) The following changes are desired by IBM.  We do not want to prohibit
any out-of-band methods from being used. 
Section 8.5.2.7, pg 19, last paragraph.  Remove the text "by processing
a Set Data Encryption page." 
Section 8.5.2.7, pg 20, first three paragraphs, change the text 
     "in the Set Data Encryption page that established the key in the
device server." 
to 
     "when the key was established in the device server." 
[Paul Entzel] I think that would work.	Or, I thi8nk both of these
paragraphs could be re-written to reference the Data Encryption
Parameters since the data they are reporting is in that structure.
EDITORIAL: 
1) Section 4.2.19.6, pg 8, sentence leading into second list, "The set
of possible data encryption scope values for an I_T nexus is limited
to:" please remove "limited to".  "limited to" might lead a reader to
infer intent that is not intended. 
2) Section 4.2.19.11, pg 11 end of 1st paragraph.  Should
"non-authenticated" be changed to "unauthenticated"? 
3) Section 8.5.2.7, pg 19.  Second to last sentence on the page: "...,
they shall be order of increasing..."  missing	the word "in". 
3) Section 8.5.3.1, pg 23, second sentence in first paragraph.	I think
"requested" should be changed to "sent". 
4) Last paragraph of pg 26: "If the device server does is not...."
delete "does". 
5) Page 28, last paragraph before section 8.5.4.  Missing D: "INCOMPLETE
KEY - ASSOCIATE DATA SET" s/b  "INCOMPLETE KEY - ASSOCIATED DATA SET" 
6) Section 8.5.4.1, pg 28, first sentence: "Several of the parameter
pages in used" delete the "in" 
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 at us.ibm.com
http://www-03.ibm.com/servers/storage/