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@us.ibm.com]
Sent: Tuesday, March 21, 2006 4:01 PM
To: Paul Entzel; T10@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@us.ibm.com
http://www-03.ibm.com/servers/storage/