Comments on 05-446r9

Wed Mar 22 09:34:52 PST 2006

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

Paul,
Thanks for the feedback.  I have some follow up comments to consider.
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/ 
"Paul Entzel" <Paul.Entzel at quantum.com> 
Sent by: owner-t10 at t10.org
03/22/2006 08:33 AM
To
Kevin D Butt/Tucson/IBM at IBMUS, <T10 at t10.org>
cc
Subject
RE: Comments on 05-446r9
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. <<Kevin Butt>>  It was my understanding that this was known 
to be a bad block (i.e. corrupted) as opposed to just a wrong key or 
algorithm.  Is my understanding in error?
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.  <<Kevin Butt>> If my 
understanding stated above is correct (i.e. the block is corrupted) then 
this Sense Key should be MEDIUM ERROR instead.	However, if I am in error, 
then I agree with your comments.
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? <<Kevin Butt>> 
 I was thinking about how Persistent Reserve handles UA's and some of the 
UA's only get established for those I_T Nexus that are registered.  I was 
think this would be similar to that.
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. <<Kevin Butt>> With PUBLIC and 
no PROHIBIT ENCRYPTION there is no way for an I_T Nexus to make sure 
encryption is not used (i.e. guarantee that if there is encryption being 
used in the SAN, that they will not be effected by it.)  I do not know 
which direction should be taken but I think it should be discussed and a 
explicit decision made on it.
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). <<Kevin Butt>>  I remember this discussion 
|from the last conference call, but I still struggled with it.  Is there 
something that can be done to make it more clear?  I think if I am this 
think headed, there will be other readers just as think headed as I am.
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.  <<Kevin Butt>> 
That would probably be better.
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/