From roweber at IEEE.org  Sat Mar  1 06:18:00 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Sat, 01 Mar 2008 08:18:00 -0600
Subject: CbCS UML 'adjustments'
Message-ID: <mailman.209.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Corrections were requested to my proposed CbCS UML figure.
The revised proposal is available as:
http://www.t10.org/ftp/t10/document.08/08-113r1.pdf
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Sat Mar  1 23:01:01 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 2 Mar 2008 00:01:01 -0700
Subject: Recent T10 documents uploaded since 2008/02/24
Message-ID: <mailman.210.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Agenda for T10 Meeting #84 March 2008
(by: John Lohmeyer)
T10/08-088r3   Uploaded: 2008/02/28   62150 bytes
ftp://ftp.t10.org/t10/document.08/08-088r3.pdf
OSD-2 CDB Continuations Definition and Usage
(by: Ralph O. Weber)
T10/08-105r0   Uploaded: 2008/02/28   323438 bytes
ftp://ftp.t10.org/t10/document.08/08-105r0.pdf
SPC-4 UML Conventions and CbCS UML Updates
(by: Ralph O. Weber)
T10/08-113r1   Uploaded: 2008/03/01   62124 bytes
ftp://ftp.t10.org/t10/document.08/08-113r1.pdf
Minutes of SAT-2 Working Group - February 22, 2008
(by: John Lohmeyer)
T10/08-114r1   Uploaded: 2008/02/25   33599 bytes
ftp://ftp.t10.org/t10/document.08/08-114r1.htm
Minutes of SAT-2 Working Group - February 22, 2008
(by: John Lohmeyer)
T10/08-114r1   Uploaded: 2008/02/25   101651 bytes
ftp://ftp.t10.org/t10/document.08/08-114r1.pdf
INCITS T11 Liaison Report, February, 2008
(by: Robert Snively)
T10/08-120r0   Uploaded: 2008/02/25   13108 bytes
ftp://ftp.t10.org/t10/document.08/08-120r0.pdf
Limitations of df/dt Specification for SSC Profiles
(by: Guillaume Fortin)
T10/08-121r0   Uploaded: 2008/02/25   328000 bytes
ftp://ftp.t10.org/t10/document.08/08-121r0.pdf
FCP Annex D Proposed Changes
(by: David Peterson)
T10/08-122r0   Uploaded: 2008/02/25   60081 bytes
ftp://ftp.t10.org/t10/document.08/08-122r0.pdf
Project Proposal: SCSI Architecture Model - 5 (SAM-5)
(by: George Penokie)
T10/08-124r0   Uploaded: 2008/02/27   67324 bytes
ftp://ftp.t10.org/t10/document.08/08-124r0.pdf
Minutes: FCP-4 and FC-SCM: Minutes of teleconference 26 February 2008
(by: Bob Nixon)
T10/08-125r0   Uploaded: 2008/02/29   13922 bytes
ftp://ftp.t10.org/t10/document.08/08-125r0.pdf
Working Drafts
--------------
Automation/Drive Interface Commands - 3 (ADC-3)
(Editor: open)
 Rev: 00       Uploaded: 2008/02/28   493454 bytes
ftp://ftp.t10.org/t10/drafts/adc3/adc3r00.pdf
SCSI Architecture Model - 4 (SAM-4)
(Editor: George Penokie)
 Rev: 13e      Uploaded: 2008/03/01   2451118 bytes
ftp://ftp.t10.org/t10/drafts/sam4/sam4r13e.pdf
SCSI Media Changer Command Set - 3 (SMC-3)
(Editor: Noud Snelder)
 Rev: 11       Uploaded: 2008/02/29   2163565 bytes
ftp://ftp.t10.org/t10/drafts/smc3/smc3r11.pdf
(Report generated on 2008/03/02 at 00:01:01)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From nathan.marushak at intel.com  Mon Mar  3 13:08:17 2008
From: nathan.marushak at intel.com (Marushak, Nathan)
Date: Mon, 3 Mar 2008 14:08:17 -0700
Subject: SAS Driver Interface Question
Message-ID: <mailman.211.1441607335.22514.t10@sandbox.t10.org>

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

Was the SAS Driver Interface (SDI) formally adopted?  If so, where can
it be found?
Thanks,
Nate


From Bill.Schmitz at lsi.com  Mon Mar  3 12:55:34 2008
From: Bill.Schmitz at lsi.com (Schmitz, Bill)
Date: Mon, 3 Mar 2008 13:55:34 -0700
Subject: SCSI auto-termination
Message-ID: <mailman.212.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Schmitz, Bill" <Bill.Schmitz at lsi.com>
*
Anybody recall how auto-termination works or where I can find some
information about it?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From MOverby at nvidia.com  Mon Mar  3 14:50:13 2008
From: MOverby at nvidia.com (Mark Overby)
Date: Mon, 03 Mar 2008 14:50:13 -0800
Subject: SAS Driver Interface Question
Message-ID: <mailman.213.1441607335.22514.t10@sandbox.t10.org>

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

The SDI project was cancelled by T10.
On 3/3/08 1:08 PM, "Marushak, Nathan" <nathan.marushak at intel.com> wrote:
> Was the SAS Driver Interface (SDI) formally adopted?	If so, where can it
be
> found?
>  
> Thanks,
> Nate
> 
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------


From Paul.Stone at Quantum.Com  Mon Mar  3 15:17:44 2008
From: Paul.Stone at Quantum.Com (Paul Stone)
Date: Mon, 3 Mar 2008 15:17:44 -0800
Subject: ADC-3 Rev 00 has been posted
Message-ID: <mailman.214.1441607335.22514.t10@sandbox.t10.org>

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

Change bars are there as well as revision history.
http://t10.org/ftp/t10/drafts/adc3/adc3r00.pdf
Paul Stone
Quantum
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.


From George.Penokie at lsi.com  Tue Mar  4 12:00:47 2008
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 4 Mar 2008 13:00:47 -0700
Subject: SCSI auto-termination
Message-ID: <mailman.215.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Penokie, George" <George.Penokie at lsi.com>
*
Bill,
I can only assume you are referring to the LVD/MSE multimode termination
that was last defined in the SPI-4 standard as we never defined anything
else that could be called auto-termination. To find information on that
you need to get a copy of SPI-4 and look in section 7.4.1 LVD/MSE
multimode termination.
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Schmitz,
Bill
Sent: Monday, March 03, 2008 2:56 PM
To: t10 at t10.org
Subject: SCSI auto-termination
* From the T10 Reflector (t10 at t10.org), posted by:
* "Schmitz, Bill" <Bill.Schmitz at lsi.com>
*
Anybody recall how auto-termination works or where I can find some
information about it?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Tue Mar  4 14:26:05 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 04 Mar 2008 15:26:05 -0700
Subject: SCSI auto-termination
Message-ID: <mailman.216.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Bill and George,
There was also a non-standard auto-termination scheme that some host adapters
used to detect whether both its internal connector and external connector
were connected to external termination. If both were terminated, the HBA
would disable its own termination. This scheme depended on there being only
one HBA. On each connector, the HBA sensed whether one of the ground lines
was actually grounded or floating. This scheme would also work with LVD.
John
At 3/4/2008 01:00 PM, Penokie, George wrote:
>* From the T10 Reflector (t10 at t10.org), posted by:
>* "Penokie, George" <George.Penokie at lsi.com>
>*
>Bill,
>
>I can only assume you are referring to the LVD/MSE multimode termination
>that was last defined in the SPI-4 standard as we never defined anything
>else that could be called auto-termination. To find information on that
>you need to get a copy of SPI-4 and look in section 7.4.1 LVD/MSE
>multimode termination.
>
>
>Bye for now, 
>George Penokie
> 
>LSI Corporation 
>3033 41st St. NW 
>Suite 100 
>Rochester, MN 55901
> 
>507-328-9017 
>george.penokie at lsi.com
>
>
>-----Original Message-----
>From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Schmitz,
>Bill
>Sent: Monday, March 03, 2008 2:56 PM
>To: t10 at t10.org
>Subject: SCSI auto-termination
>
>* From the T10 Reflector (t10 at t10.org), posted by:
>* "Schmitz, Bill" <Bill.Schmitz at lsi.com>
>*
>Anybody recall how auto-termination works or where I can find some
>information about it?
>
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at t10.org
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From George.Penokie at lsi.com  Wed Mar  5 06:08:46 2008
From: George.Penokie at lsi.com (Penokie, George)
Date: Wed, 5 Mar 2008 07:08:46 -0700
Subject: Today's SAM-4/SES-2 letter ballot review
Message-ID: <mailman.217.1441607335.22514.t10@sandbox.t10.org>

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

This WebEx link should work for today's meeting.
Topic: SAM/SES Letter Ballot review 
Date: Wednesday, March 5, 2008 
Time: 10:00 am, Central Standard Time (GMT -06:00, Chicago) 
Meeting Number: 573 337 284 
Meeting Password: review 
Please click the link below to see more information about the meeting,
including its agenda, or to join the meeting. 
------------------------------------------------------- 
To join the online meeting 
------------------------------------------------------- 
1. Go to
https://lsilogic.webex.com/lsilogic/j.php?ED=104169617&UID=0&PW=1c884216
12545445 
2. Enter your name and email address. 
3. Enter the meeting password: review 
4. Click "Join Now". 
5. Follow the instructions that appear on your screen. 
------------------------------------------------------- 
To join the teleconference only 
------------------------------------------------------- 
Conference Access: 
Toll free: 1-800-531-5745 
Toll: 1-719-955-2349 
Passcode: 5073289017 
------------------------------------------------------- 
For assistance 
------------------------------------------------------- 
1. Go to https://lsilogic.webex.com/lsilogic/mc 
2. On the left navigation bar, click "Support". 
You can contact me at: 
george.penokie at lsi.com 
1-507-3289017 
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com


From mikeb at bustrace.com  Wed Mar  5 12:01:11 2008
From: mikeb at bustrace.com (Mike Berhan)
Date: Wed, 5 Mar 2008 12:01:11 -0800
Subject: SPC Read Attribute clarification request
Message-ID: <mailman.218.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
Offset 8-9 of the Read Attribute CDB is defined as the "FIRST ATTRIBUTE
IDENTIFIER."  The definition of this field, from SPC-4, is:
Quote #1:  "The FIRST ATTRIBUTE IDENTIFIER field specifies the attribute
identifier of the first attribute to be returned. If the specified attribute
is in the unsupported state or nonexistent state (see 5.10), the READ
ATTRIBUTE command shall be terminated with CHECK CONDITION status, with the
sense key set to ILLEGAL REQUEST, and the additional sense code set to
INVALID FIELD IN CDB."
My questions are for Service Action 00h - ATTRIBUTE VALUES.  SPC states:
Quote #2:  "The READ ATTRIBUTE command with ATTRIBUTE VALUES service action
returns parameter data containing the attributes specified by the PARTITION
NUMBER, VOLUME NUMBER, and FIRST ATTRIBUTE IDENTIFIER fields in the CDB.
The returned parameter data shall contain the requested attributes in
ascending numerical order by attribute identifier value and in the format
shown in table 146 "
For the sake of discussion, let's say my device supports the following
Attribute IDs:
0003h
0401h
0408h
Question #1:  If a Read Attribute - Attribute Values - Attribute ID = 0000h
is submitted to the device, should it return an invalid field in CDB check
condition (per Quote #1 above) or should it simply return an array of
attributes with the Attribute 0 entry = 0003h, Attribute 1 = 0401h,
Attribute 2 = 0408h?  I have two devices from two different vendors that
handle it differently.
Question #2:  If a Read Attribute - Attribute Values - Attribute ID = 0401h
is submitted to the device, should the device return only attribute 0401h or
should it return 0401h followed by 0408h.  Here too, the two devices behave
differently.
In my reading of the specification, I believe SPC is telling me that, for
Question #1, the check condition should occur.	For Question #2, I believe
it should return 0401h followed by 0408h.  Is this the correct
understanding?
Thank you for the clarification.
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Vit.Novak at Sun.COM  Wed Mar  5 13:44:01 2008
From: Vit.Novak at Sun.COM (Vit Novak)
Date: Wed, 05 Mar 2008 13:44:01 -0800
Subject: SCSI auto-termination
Message-ID: <mailman.219.1441607335.22514.t10@sandbox.t10.org>

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

Bill,
I've done a lot of auto-termination in the past based on the principle 
described so aptly by John Lohmeyer below. Any parallel SCSI  device, 
8-bit narrow, 16-bit or 32-bit wide, single ended or LVD, can sense if 
it is the last device on the SCSI bus/chain by testing any  dedicated 
ground pin whether it is grounded or floating. It better  be the OUT	
:-)   pin.  
vit-
John Lohmeyer wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * John Lohmeyer <lohmeyer at t10.org>
> *
> Bill and George,
>
> There was also a non-standard auto-termination scheme that some host
adapters used to detect whether both its internal connector and external
connector were connected to external termination. If both were terminated,
the HBA would disable its own termination. This scheme depended on there
being only one HBA. On each connector, the HBA sensed whether one of the
ground lines was actually grounded or floating. This scheme would also work
with LVD.
>
> John
>
> At 3/4/2008 01:00 PM, Penokie, George wrote:
>   
>> * From the T10 Reflector (t10 at t10.org), posted by:
>> * "Penokie, George" <George.Penokie at lsi.com>
>> *
>> Bill,
>>
>> I can only assume you are referring to the LVD/MSE multimode termination
>> that was last defined in the SPI-4 standard as we never defined anything
>> else that could be called auto-termination. To find information on that
>> you need to get a copy of SPI-4 and look in section 7.4.1 LVD/MSE
>> multimode termination.
>>
>>
>> Bye for now, 
>> George Penokie
>>
>> LSI Corporation 
>> 3033 41st St. NW 
>> Suite 100 
>> Rochester, MN 55901
>>
>> 507-328-9017 
>> george.penokie at lsi.com
>>
>>
>> -----Original Message-----
>> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Schmitz,
>> Bill
>> Sent: Monday, March 03, 2008 2:56 PM
>> To: t10 at t10.org
>> Subject: SCSI auto-termination
>>
>> * From the T10 Reflector (t10 at t10.org), posted by:
>> * "Schmitz, Bill" <Bill.Schmitz at lsi.com>
>> *
>> Anybody recall how auto-termination works or where I can find some
>> information about it?
>>
>>
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>     
>
> --
> John Lohmeyer 		 Email: lohmeyer at t10.org
> LSI Corp.			 Voice: +1-719-533-7560
> 4420 ArrowsWest Dr.		  Cell: +1-719-338-1642
> Colo Spgs, CO 80907
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>   


From Paul.Stone at quantum.com  Wed Mar  5 18:09:01 2008
From: Paul.Stone at quantum.com (Paul Stone)
Date: Wed, 5 Mar 2008 18:09:01 -0800
Subject: ADC-3 Rev 00a has been posted
Message-ID: <mailman.220.1441607335.22514.t10@sandbox.t10.org>

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

The only change was to enable hyperlinks in the PDF output.  Change bars
are still there as before.
http://www.t10.org/ftp/t10/drafts/adc3/adc3r00a.pdf
Paul Stone
Quantum
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.


From roweber at IEEE.org  Wed Mar  5 18:47:14 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Wed, 05 Mar 2008 20:47:14 -0600
Subject: Bug in 08-101r0 (SPC-4 =?windows-1252?Q?=96_CbCS_field_byt?=
 =?windows-1252?Q?e_alignment_changes=29?=
Message-ID: <mailman.221.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
08-101r0 table x1 shows the CbCS Method coded values as
16-bit quantities.
This is inconsistent with 07-454r5 in which table 20
(capability format) show the CbCS Method field as
an 8-bit field.
Since there are no reserved bytes in the capability
format and since the capability is consistently shown
as 72 bytes in length, I am incorporating CbCS Method
as a 8-bit value.
08-101r0 might as well be revised to follow the rest
of the CbCS definition.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From SIVANT at il.ibm.com  Wed Mar  5 20:54:51 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Wed, 5 Mar 2008 23:54:51 -0500
Subject: =?UTF-8?B?UmU6IEJ1ZyBpbiAwOC0xMDFyMCAoU1BDLTQg4oCTIENiQ1MgZmllbGQ=?=
 =?UTF-8?B?IGJ5dGUgYWxpZ25tZW50IGNoYW5nZXMp?=
Message-ID: <mailman.222.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
I'm afraid there is also a bug in 07-454r5
The CBCS METHOD field in the Capability descriptor (table 20) is 8 bits,
but the values in table 22 are coded in 16 bit format. The intention is to
use 8 bits so the coded values in table 22 should be adjusted to 8 bit
format (00h instead of 0000h and so on). I think that can be considered
editorial.
And we'll get 08-101r0 table x1 revised accordingly, such that each
supported CbCS method will be 3 reserved bytes and 1 for the method code
instead of 2 and 2.
- Sivan.
	     Ralph Weber						   
	     <roweber at IEEE.org						   
	     >								To 
	     Sent by:		       "'t10 at t10.org'" <t10 at t10.org>	   
	     owner-t10 at t10.org						cc 
								   Subject 
	     03/05/2008 09:47	       Bug in 08-101r0 (SPC-4 ??? CbCS field 
	     PM 		       byte alignment changes)		   
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
08-101r0 table x1 shows the CbCS Method coded values as
16-bit quantities.
This is inconsistent with 07-454r5 in which table 20
(capability format) show the CbCS Method field as
an 8-bit field.
Since there are no reserved bytes in the capability
format and since the capability is consistently shown
as 72 bytes in length, I am incorporating CbCS Method
as a 8-bit value.
08-101r0 might as well be revised to follow the rest
of the CbCS definition.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Thu Mar  6 04:31:08 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Thu, 06 Mar 2008 06:31:08 -0600
Subject: Bug in 08-101r0 (SPC-4 =?UTF-8?B?4oCTIENiQ1MgZmllbGQgYnl0ZSBh?=
 =?UTF-8?B?bGlnbm1lbnQgY2hhbmdlcyk=?=
Message-ID: <mailman.223.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Sivan,
The only possibly substantive change was making the
vendor specific range F0h - FEh, but ...
Something had to be done and it was.
All the best,
.Ralph
Sivan Tal wrote:
> Ralph,
>
> I'm afraid there is also a bug in 07-454r5
>
> The CBCS METHOD field in the Capability descriptor (table 20) is 8 bits,
> but the values in table 22 are coded in 16 bit format. The intention is to
> use 8 bits so the coded values in table 22 should be adjusted to 8 bit
> format (00h instead of 0000h and so on). I think that can be considered
> editorial.
>
> And we'll get 08-101r0 table x1 revised accordingly, such that each
> supported CbCS method will be 3 reserved bytes and 1 for the method code
> instead of 2 and 2.
>
> - Sivan.
>
>
>
>									     
>	       Ralph Weber						     
>	       <roweber at IEEE.org					     
>	       >							  To 
>	       Sent by: 		 "'t10 at t10.org'" <t10 at t10.org>	     
>	       owner-t10 at t10.org					  cc 
>									     
>								     Subject 
>	       03/05/2008 09:47 	 Bug in 08-101r0 (SPC-4 ??? CbCS
field 
>	       PM			 byte alignment changes)	     
>									     
>									     
>									     
>									     
>									     
>									     
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> 08-101r0 table x1 shows the CbCS Method coded values as
> 16-bit quantities.
>
> This is inconsistent with 07-454r5 in which table 20
> (capability format) show the CbCS Method field as
> an 8-bit field.
>
> Since there are no reserved bytes in the capability
> format and since the capability is consistently shown
> as 72 bytes in length, I am incorporating CbCS Method
> as a 8-bit value.
>
> 08-101r0 might as well be revised to follow the rest
> of the CbCS definition.
>
> All the best,
>
> .Ralph
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>   
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at ieee.org  Thu Mar  6 05:15:38 2008
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 06 Mar 2008 07:15:38 -0600
Subject: CbCS 'correction' proposals uploaded
Message-ID: <mailman.224.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I have uploaded two proposals to amend/correct the
CbCS definition as it will appear in SPC-4 r13.
http://www.t10.org/ftp/t10/document.08/08-128r0.pdf
suggests the following changes in the RECEIVE CREDENTIAL
command:
+ correct the SA usage technique
+ make the CDB format something OSD can use for similar needs
+ fix other minor defects
http://www.t10.org/ftp/t10/document.08/08-129r0.pdf
suggests some additional CbCS capability validation requirements
CbCS has not yet been fully incorporated in the SPC-4 sources.
I cannot guarantee that these are the last CbCS-related
proposals to be posted.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Thu Mar  6 07:31:25 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 6 Mar 2008 08:31:25 -0700
Subject: 08-101r1 SPC-4: CbCS field byte alignment changes uploaded
Message-ID: <mailman.225.1441607335.22514.t10@sandbox.t10.org>

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

An update to SPC-4: CbCS field byte alignment changes has been uploaded.
   http://www.t10.org/ftp/t10/document.08/08-101r1.pdf
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


From Harry.Mason at lsi.com  Thu Mar  6 08:35:55 2008
From: Harry.Mason at lsi.com (Mason, Harry)
Date: Thu, 6 Mar 2008 09:35:55 -0700
Subject: [STA Members] STA Meeting Notice: Monday March 10th "Beyond SAS-2"
	- continuation discussion
Message-ID: <mailman.226.1441607335.22514.t10@sandbox.t10.org>

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

A continuation of the "Beyond SAS-2" discussion, hosted by the SCSI
Trade Association, will be held at the Hilton Raleigh Durham Airport
hotel.	
This event is scheduled to begin at 6:30pm (room TBD)  
After a brief introduction by STA, we will hear presentations from the
flowing companies.
-	  Molex, Jay Neer - 10 Minutes
-	  Seagate, Marty Czekalski - 10 Minutes
-	  Emulex - 15 Minutes
-	  Tyco - 15 Minutes
-	  PMC Sierra - 15 Minutes
-	  Quellan - 15 Minutes
-	  Finisar - 15 Minutes
Looking forward to lively and spirited discussion.
Thanks
Harry
719-331-0994


From Harry.Mason at lsi.com  Thu Mar  6 08:35:55 2008
From: Harry.Mason at lsi.com (Mason, Harry)
Date: Thu, 6 Mar 2008 09:35:55 -0700
Subject: STA Meeting Notice: Monday March 10th  "Beyond SAS-2" - continuation discussion
Message-ID: <mailman.227.1441607335.22514.t10@sandbox.t10.org>

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

A continuation of the "Beyond SAS-2" discussion, hosted by the SCSI
Trade Association, will be held at the Hilton Raleigh Durham Airport
hotel.	
This event is scheduled to begin at 6:30pm (room TBD)  
After a brief introduction by STA, we will hear presentations from the
flowing companies.
-	  Molex, Jay Neer - 10 Minutes
-	  Seagate, Marty Czekalski - 10 Minutes
-	  Emulex - 15 Minutes
-	  Tyco - 15 Minutes
-	  PMC Sierra - 15 Minutes
-	  Quellan - 15 Minutes
-	  Finisar - 15 Minutes
Looking forward to lively and spirited discussion.
Thanks
Harry
719-331-0994


From SIVANT at il.ibm.com  Thu Mar  6 14:25:53 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Thu, 6 Mar 2008 17:25:53 -0500
Subject: Comments on: CbCS 'correction' proposals
Message-ID: <mailman.228.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
As expected, 40 pages of SCSI standard text produce quite a few bugs. Some
of my comments are suggestions for additional bug fixes.
Thanks,
Sivan Tal.
Comments on 08-128r0
~~~~~~~~~~~~~~~~~~~~
Comment 1:
Thanks for correcting the SA usage. However, one of the "features" didn't
make it to the correct usage. That is the requirement that the creation of
the SA had included an authentication step.
Now, since the minimum SA parameters do not include the information
required to determine whether the authentication step had been skipped or
not, this involves maintaining additional info that is not specified in the
standard. While this can still be done, I suspect a better way to require
authentication is to make a change to the IKEv2-SCSI part as follows:
If the selected USAGE_TYPE SA parameter is "CbCS authentication and
credential encryption" then the authentication step must not be skipped (in
other words, SA_AUTH_NONE must not be selected).
Comment 2:
A flaw in 07-454r5 that I suggest fixing here. In 6.19.2.2 (RECEIVE
CREDENTIAL decrypted parameter data) it says that "The contents of the CbCS
capability descriptor are defined in 6.19.2.3". That's right, but there's
more to it. The Designation Descriptor field in that Capability descriptor
shall match the one in the RECEIVE CREDENTIAL command parameter.
Comment 3:
The requirement specified in comment 2 provides that any credential
prepared by a Security Manager will have designation type NAA (because
that's the only one allowed in the request). However, since the standard
provides for self-generated credentials (see the BASIC CbCS method), I
suggest requiring NAA in the Capability Designation Descriptor field in
6.19.2.3 (CbCS capability descriptor).
Comment 4:
The RECEIVE CREDENTIAL command must always include a logical unit (or SCSI
device) and optionally a volume designator. When CbCS is used with volumes,
the Capability field only contains identification of the volume, but the
request must also include identification of the LU through which the volume
is to be accessed. This allows the Security Manager to use the right shared
key for the ICV. The new way you constructed the CDB allows for either LU
or volume identifier. It should be either LU or LU+volume.
Comment 5:
In 6.19.1.3 the text "???the MAM ATTRIBUTE field" should be "the CREDENTIAL
REQUEST DESCRIPTOR field".
Comment 6:
Table 180 ??? Capability format values : This should be renamed to
"Credential format values". Note that 'Credential' is what the CbCS
Management device server sends to the Secure CDB Originator, but the
Enforcement Manager never gets a 'Credential'. It only gets a 'Capability'
and 'ICV'. The group had decided that a 'CbCS Capability' has a single
format and future formats will define new capability types and extension
types.
The rationale is that the current (only) credential format - 1h - is used
in conjunction with CbCS extension. In the future, new credential formats
may be defined, in conjunction with new extension types (say CbCSv2, CbCSv3
type extensions). Moreover, new credential formats may be defined to
facilitate non-CbCS credentials, as the SCSI command security model
supports multiple techniques (We spent so much time on this - you wouldn't
forget that ;-)
Comments on 08-129r0
~~~~~~~~~~~~~~~~~~~~
I'm fine with the changes, and I suggest another one. I'm not writing the
exact proposed change here, rather explain what is to be added and Ralph
can do it best:,
If the KEY VERSION field contains 0000 0000h or FFFF FFFFh or a value that
doesn't exist for the logical unit and returned in the Attributes CbCS page
(see 6.1.5 in 07-454r5), then the validation shall also fail.
owner-t10 at t10.org wrote on 03/06/2008 08:15:38 AM:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> I have uploaded two proposals to amend/correct the
> CbCS definition as it will appear in SPC-4 r13.
>
> http://www.t10.org/ftp/t10/document.08/08-128r0.pdf
> suggests the following changes in the RECEIVE CREDENTIAL
> command:
> + correct the SA usage technique
> + make the CDB format something OSD can use for similar needs
> + fix other minor defects
>
> http://www.t10.org/ftp/t10/document.08/08-129r0.pdf
> suggests some additional CbCS capability validation requirements
>
> CbCS has not yet been fully incorporated in the SPC-4 sources.
> I cannot guarantee that these are the last CbCS-related
> proposals to be posted.
>
> All the best,
>
> .Ralph
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Thu Mar  6 14:41:00 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Thu, 06 Mar 2008 16:41:00 -0600
Subject: LU+Volume
Message-ID: <mailman.229.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Sivan Tal wrote:
> <snip>
>
> Comment 4:
> The RECEIVE CREDENTIAL command must always include a logical unit (or SCSI
> device) and optionally a volume designator. When CbCS is used with volumes,
> the Capability field only contains identification of the volume, but the
> request must also include identification of the LU through which the volume
> is to be accessed. This allows the Security Manager to use the right shared
> key for the ICV. The new way you constructed the CDB allows for either LU
> or volume identifier. It should be either LU or LU+volume.
Since the LU information is not in the capability, how does
the enforcement manager determine the correct shared key
for use in its reconstruction of the capkey?
I spoke with Kevin about this, and the intention is to make this
credential format applicable to a volume regardless of the LU in
which it is mounted. Therefore, I am concerned that there are
some undesirable hidden connections here.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From SIVANT at il.ibm.com  Thu Mar  6 19:54:28 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Thu, 6 Mar 2008 22:54:28 -0500
Subject: LU+Volume
Message-ID: <mailman.230.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Well, the enforcement manager will have to figure it out, but I don't think
this is an issue because the command is received at a logical unit or
device. If the enforcement manager is contained in a device server, then it
is contained in a logical unit (per the CbCS UML diagram) and it should use
the logical unit's key. If it is contained in a target device, it should
use the device's "global" key. There is a clause on shared keys that
explain the distinction between LU keys and global keys.
Regards, Sivan.
owner-t10 at t10.org wrote on 03/06/2008 05:41:00 PM:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> Sivan Tal wrote:
> > <snip>
> >
> > Comment 4:
> > The RECEIVE CREDENTIAL command must always include a logical unit (or
SCSI
> > device) and optionally a volume designator. When CbCS is used with
volumes,
> > the Capability field only contains identification of the volume, but
the
> > request must also include identification of the LU through which the
volume
> > is to be accessed. This allows the Security Manager to use the right
shared
> > key for the ICV. The new way you constructed the CDB allows for either
LU
> > or volume identifier. It should be either LU or LU+volume.
> Since the LU information is not in the capability, how does
> the enforcement manager determine the correct shared key
> for use in its reconstruction of the capkey?
>
> I spoke with Kevin about this, and the intention is to make this
> credential format applicable to a volume regardless of the LU in
> which it is mounted. Therefore, I am concerned that there are
> some undesirable hidden connections here.
>
> All the best,
>
> .Ralph
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Fri Mar  7 05:51:34 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Fri, 07 Mar 2008 07:51:34 -0600
Subject: LU+Volume
Message-ID: <mailman.231.1441607335.22514.t10@sandbox.t10.org>

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

Sivan,
The description of the enforcement manager's behavior
shown below appears to conflict with Kevin's understanding
of what those who requested CbCS support for volumes wanted.
The Volume Credential is valid for only one logical unit
(or possibly all the logical units in one SCSI target device).
Any other logical unit will have a different key and therefore
be unable to construct the correct capkey associated with the
Volume Credential. Therefore, use of the volume in other
logical units appears to be prohibited.
I am no longer certain that CbCS Volume support functions
as intended.
All the best,
.Ralph
Sivan Tal wrote:
> Well, the enforcement manager will have to figure it out, but I don't think
> this is an issue because the command is received at a logical unit or
> device. If the enforcement manager is contained in a device server, then it
> is contained in a logical unit (per the CbCS UML diagram) and it should use
> the logical unit's key. If it is contained in a target device, it should
> use the device's "global" key. There is a clause on shared keys that
> explain the distinction between LU keys and global keys.
>
> Regards, Sivan.
>
> owner-t10 at t10.org wrote on 03/06/2008 05:41:00 PM:
>
>   
>> * From the T10 Reflector (t10 at t10.org), posted by:
>> * Ralph Weber <roweber at ieee.org>
>> *
>> Sivan Tal wrote:
>>     
>>> <snip>
>>>
>>> Comment 4:
>>> The RECEIVE CREDENTIAL command must always include a logical unit (or
>>>	  
> SCSI
>   
>>> device) and optionally a volume designator. When CbCS is used with
>>>	  
> volumes,
>   
>>> the Capability field only contains identification of the volume, but
>>>	  
> the
>   
>>> request must also include identification of the LU through which the
>>>	  
> volume
>   
>>> is to be accessed. This allows the Security Manager to use the right
>>>	  
> shared
>   
>>> key for the ICV. The new way you constructed the CDB allows for either
>>>	  
> LU
>   
>>> or volume identifier. It should be either LU or LU+volume.
>>>	  
>> Since the LU information is not in the capability, how does
>> the enforcement manager determine the correct shared key
>> for use in its reconstruction of the capkey?
>>
>> I spoke with Kevin about this, and the intention is to make this
>> credential format applicable to a volume regardless of the LU in
>> which it is mounted. Therefore, I am concerned that there are
>> some undesirable hidden connections here.
>>
>> All the best,
>>
>> .Ralph
>>
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>     
>
>
>
>
>   


From roweber at IEEE.org  Fri Mar  7 05:56:03 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Fri, 07 Mar 2008 07:56:03 -0600
Subject: LU+Volume+"global" keys
Message-ID: <mailman.232.1441607335.22514.t10@sandbox.t10.org>

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

Sivan,
I appear to have the wrong understanding of SCSI target device
credentials.
What I have read so far in CbCS says that SCSI target device
credentials are used only with well-known logical units.
Therefore, the "global" key described below applies only
to enforcement manager actions on behalf of a well-known
logical unit.
Since the tape drives that are used to access volumes are
never well-known logical unit, it appears to me that the
"global" key case described below does not exist.
All the best,
.Ralph
Sivan Tal wrote:
> Well, the enforcement manager will have to figure it out, but I don't think
> this is an issue because the command is received at a logical unit or
> device. If the enforcement manager is contained in a device server, then it
> is contained in a logical unit (per the CbCS UML diagram) and it should use
> the logical unit's key. If it is contained in a target device, it should
> use the device's "global" key. There is a clause on shared keys that
> explain the distinction between LU keys and global keys.
>
> Regards, Sivan.
>
> owner-t10 at t10.org wrote on 03/06/2008 05:41:00 PM:
>
>   
>> * From the T10 Reflector (t10 at t10.org), posted by:
>> * Ralph Weber <roweber at ieee.org>
>> *
>> Sivan Tal wrote:
>>     
>>> <snip>
>>>
>>> Comment 4:
>>> The RECEIVE CREDENTIAL command must always include a logical unit (or
>>>	  
> SCSI
>   
>>> device) and optionally a volume designator. When CbCS is used with
>>>	  
> volumes,
>   
>>> the Capability field only contains identification of the volume, but
>>>	  
> the
>   
>>> request must also include identification of the LU through which the
>>>	  
> volume
>   
>>> is to be accessed. This allows the Security Manager to use the right
>>>	  
> shared
>   
>>> key for the ICV. The new way you constructed the CDB allows for either
>>>	  
> LU
>   
>>> or volume identifier. It should be either LU or LU+volume.
>>>	  
>> Since the LU information is not in the capability, how does
>> the enforcement manager determine the correct shared key
>> for use in its reconstruction of the capkey?
>>
>> I spoke with Kevin about this, and the intention is to make this
>> credential format applicable to a volume regardless of the LU in
>> which it is mounted. Therefore, I am concerned that there are
>> some undesirable hidden connections here.
>>
>> All the best,
>>
>> .Ralph
>>
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>     
>
>
>
>
>   


From SIVANT at il.ibm.com  Fri Mar  7 07:38:53 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Fri, 7 Mar 2008 10:38:53 -0500
Subject: LU+Volume
Message-ID: <mailman.233.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
The current draft reflects the original intention for volume support.
The intention is indeed that a credential to access a volume can only be
used with a specific logical unit, or a specific device.
The application client (or whatever entity that retrieves a credential on
its behalf) is expected to know what device/LU it is going to use to access
the volume. Although a volume can be moved between devices, this should not
happen too frequently. Typically the LU doesn't change for the duration of
a backup/restore session that writes/reads a volume.
Certain implementation may share keys across multiple devices to allow
application clients to be totally unaware of the logical units they are
sending commands to, from access control perspective (for what it's worth).
A model that supports volume credentials that are not bound to a LU or
device would require that the CbCS Management application client sends
"volume keys" to target devices. This is a significant change, and I'm not
sure what's the value in it because ultimately it comes down back to having
to know to which LU that volume key is to be sent.
I will discuss this with Kevin, and we will update if we find anything
needs to be changed.
Regards, Sivan.
	     Ralph Weber						   
	     <roweber at IEEE.org						   
	     >								To 
	     Sent by:		       "'t10 at t10.org'" <t10 at t10.org>	   
	     owner-t10 at t10.org						cc 
								   Subject 
	     03/07/2008 08:51	       Re: LU+Volume			   
	     AM 							   
Sivan,
The description of the enforcement manager's behavior
shown below appears to conflict with Kevin's understanding
of what those who requested CbCS support for volumes wanted.
The Volume Credential is valid for only one logical unit
(or possibly all the logical units in one SCSI target device).
Any other logical unit will have a different key and therefore
be unable to construct the correct capkey associated with the
Volume Credential. Therefore, use of the volume in other
logical units appears to be prohibited.
I am no longer certain that CbCS Volume support functions
as intended.
All the best,
.Ralph
Sivan Tal wrote:
      Well, the enforcement manager will have to figure it out, but I don't
      think
      this is an issue because the command is received at a logical unit or
      device. If the enforcement manager is contained in a device server,
      then it
      is contained in a logical unit (per the CbCS UML diagram) and it
      should use
      the logical unit's key. If it is contained in a target device, it
      should
      use the device's "global" key. There is a clause on shared keys that
      explain the distinction between LU keys and global keys.
      Regards, Sivan.
      owner-t10 at t10.org wrote on 03/06/2008 05:41:00 PM:
	    * From the T10 Reflector (:t10 at t10.org), posted by:
	    * Ralph Weber <roweber at ieee.org>
	    *
	    Sivan Tal wrote:
		  <snip>
		  Comment 4:
		  The RECEIVE CREDENTIAL command must always include a
		  logical unit (or
      SCSI
		  device) and optionally a volume designator. When CbCS is
		  used with
      volumes,
		  the Capability field only contains identification of the
		  volume, but
      the
		  request must also include identification of the LU
		  through which the
      volume
		  is to be accessed. This allows the Security Manager to
		  use the right
      shared
		  key for the ICV. The new way you constructed the CDB
		  allows for either
      LU
		  or volume identifier. It should be either LU or LU
		  +volume.
	    Since the LU information is not in the capability, how does
	    the enforcement manager determine the correct shared key
	    for use in its reconstruction of the capkey?
	    I spoke with Kevin about this, and the intention is to make
	    this
	    credential format applicable to a volume regardless of the LU
	    in
	    which it is mounted. Therefore, I am concerned that there are
	    some undesirable hidden connections here.
	    All the best,
	    .Ralph
	    *
	    * For T10 Reflector information, send a message with
	    * 'info t10' (no quotes) in the message body to
	    majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From SIVANT at il.ibm.com  Fri Mar  7 07:50:55 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Fri, 7 Mar 2008 10:50:55 -0500
Subject: "global" keys
Message-ID: <mailman.234.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
"Global keys" (may I also call them "device keys" informally) are designed
to be used for credentials of all LUs within a target device.
The LU's secure CDB processor uses the device's enforcement manager (refer
to the CbCS UML diagram) to validate the credential (which was received in
a command within a "regular" LU).
It is assumed that the security manager knows the association between
logical units and target devices, so when it receives a request for
credential with given LU ID, it knows which device (global) key to use.
Regards, Sivan.
	     Ralph Weber						   
	     <roweber at IEEE.org						   
	     >								To 
	     Sent by:		       "'t10 at t10.org'" <t10 at t10.org>	   
	     owner-t10 at t10.org						cc 
								   Subject 
	     03/07/2008 08:56	       Re: LU+Volume+"global" keys	   
	     AM 							   
Sivan,
I appear to have the wrong understanding of SCSI target device
credentials.
What I have read so far in CbCS says that SCSI target device
credentials are used only with well-known logical units.
Therefore, the "global" key described below applies only
to enforcement manager actions on behalf of a well-known
logical unit.
Since the tape drives that are used to access volumes are
never well-known logical unit, it appears to me that the
"global" key case described below does not exist.
All the best,
.Ralph
Sivan Tal wrote:
      Well, the enforcement manager will have to figure it out, but I don't
      think
      this is an issue because the command is received at a logical unit or
      device. If the enforcement manager is contained in a device server,
      then it
      is contained in a logical unit (per the CbCS UML diagram) and it
      should use
      the logical unit's key. If it is contained in a target device, it
      should
      use the device's "global" key. There is a clause on shared keys that
      explain the distinction between LU keys and global keys.
      Regards, Sivan.
      owner-t10 at t10.org wrote on 03/06/2008 05:41:00 PM:
	    * From the T10 Reflector (:t10 at t10.org), posted by:
	    * Ralph Weber <roweber at ieee.org>
	    *
	    Sivan Tal wrote:
		  <snip>
		  Comment 4:
		  The RECEIVE CREDENTIAL command must always include a
		  logical unit (or
      SCSI
		  device) and optionally a volume designator. When CbCS is
		  used with
      volumes,
		  the Capability field only contains identification of the
		  volume, but
      the
		  request must also include identification of the LU
		  through which the
      volume
		  is to be accessed. This allows the Security Manager to
		  use the right
      shared
		  key for the ICV. The new way you constructed the CDB
		  allows for either
      LU
		  or volume identifier. It should be either LU or LU
		  +volume.
	    Since the LU information is not in the capability, how does
	    the enforcement manager determine the correct shared key
	    for use in its reconstruction of the capkey?
	    I spoke with Kevin about this, and the intention is to make
	    this
	    credential format applicable to a volume regardless of the LU
	    in
	    which it is mounted. Therefore, I am concerned that there are
	    some undesirable hidden connections here.
	    All the best,
	    .Ralph
	    *
	    * For T10 Reflector information, send a message with
	    * 'info t10' (no quotes) in the message body to
	    majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gourgen at quellan.com  Fri Mar  7 15:00:52 2008
From: gourgen at quellan.com (Gourgen Oganessyan)
Date: Fri, 7 Mar 2008 18:00:52 -0500
Subject: Active cable proposal
Message-ID: <mailman.235.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Gourgen Oganessyan" <gourgen at quellan.com>
*
All,
I have uploaded the update to the active cable proposal (08-052r2) and
the supporting presentation (08-103r2).
Best,
Gourgen Oganessyan
Quellan Inc.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Fri Mar  7 15:21:01 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 7 Mar 2008 16:21:01 -0700
Subject: 08-137r0: FCP-4: Defects in FCP-4r00a
Message-ID: <mailman.236.1441607335.22514.t10@sandbox.t10.org>

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

I have uploaded a proposal that lists issues with FCP-4 for your review
2008/03/07 16:16:13 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.08/08-137r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
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


From roweber at IEEE.org  Sat Mar  8 16:25:21 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Sat, 08 Mar 2008 18:25:21 -0600
Subject: Constraints on SPC-4 SA creation based on Usage Type
Message-ID: <mailman.237.1441607335.22514.t10@sandbox.t10.org>

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

> -------- Original Message --------
> Subject:	Comments on: CbCS 'correction' proposals
> Date: 	Thu, 6 Mar 2008 17:25:53 -0500
> From: 	Sivan Tal <SIVANT at il.ibm.com>
> To:	Ralph Weber <roweber at ieee.org>
> CC:	owner-t10 at t10.org, "'t10 at t10.org'" <t10 at t10.org>, Kevin D Butt 
> <kdbutt at us.ibm.com>, "David Black" <Black_David at emc.com>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Sivan Tal <SIVANT at il.ibm.com>
> *
> <snip>
>
> Comment 1:
> Thanks for correcting the SA usage. However, one of the "features" didn't
> make it to the correct usage. That is the requirement that the creation of
> the SA had included an authentication step.
> Now, since the minimum SA parameters do not include the information
> required to determine whether the authentication step had been skipped or
> not, this involves maintaining additional info that is not specified in the
> standard. While this can still be done, I suspect a better way to require
> authentication is to make a change to the IKEv2-SCSI part as follows:
> If the selected USAGE_TYPE SA parameter is "CbCS authentication and
> credential encryption" then the authentication step must not be skipped (in
> other words, SA_AUTH_NONE must not be selected).
>
> <gigantic snip>
>   
Hopefully, the following new proposal addresses this issue.
http://www.t10.org/ftp/t10/document.08/08-138r0.pdf
However, I have not had time to confirm the suitability of the
proposal with the SA creation gurus (i.e., things may get a
little dicey when CAP reviews the plan).
All the best,
.Ralph


From roweber at IEEE.org  Sat Mar  8 17:31:52 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Sat, 08 Mar 2008 19:31:52 -0600
Subject: Comments on: CbCS 'correction' proposals
Message-ID: <mailman.238.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Sivan Tal wrote:
> <snip>
>
> Comment 4:
> The RECEIVE CREDENTIAL command must always include a logical unit (or SCSI
> device) and optionally a volume designator. When CbCS is used with volumes,
> the Capability field only contains identification of the volume, but the
> request must also include identification of the LU through which the volume
> is to be accessed. This allows the Security Manager to use the right shared
> key for the ICV. The new way you constructed the CDB allows for either LU
> or volume identifier. It should be either LU or LU+volume.
>
> Comment 5:
> In 6.19.1.3 the text "the MAM ATTRIBUTE field" should be "the CREDENTIAL
> REQUEST DESCRIPTOR field".
>
> Comment 6:
> Table 180 ? Capability format values : This should be renamed to
> "Credential format values". Note that 'Credential' is what the CbCS
> Management device server sends to the Secure CDB Originator, but the
> Enforcement Manager never gets a 'Credential'. It only gets a 'Capability'
> and 'ICV'. The group had decided that a 'CbCS Capability' has a single
> format and future formats will define new capability types and extension
> types.
> The rationale is that the current (only) credential format - 1h - is used
> in conjunction with CbCS extension. In the future, new credential formats
> may be defined, in conjunction with new extension types (say CbCSv2, CbCSv3
> type extensions). Moreover, new credential formats may be defined to
> facilitate non-CbCS credentials, as the SCSI command security model
> supports multiple techniques (We spent so much time on this - you wouldn't
> forget that ;-)
> <snip>
>   
Hopefully, these comments are addressed by the just uploaded:
http://www.t10.org/ftp/t10/document.08/08-128r1.pdf
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Sat Mar  8 17:50:59 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Sat, 08 Mar 2008 19:50:59 -0600
Subject: Capability must contain LU designation descriptor
Message-ID: <mailman.239.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Sivan Tal wrote:
> <snip>
>
> Comment 2:
> A flaw in 07-454r5 that I suggest fixing here. In 6.19.2.2 (RECEIVE
> CREDENTIAL decrypted parameter data) it says that "The contents of the CbCS
> capability descriptor are defined in 6.19.2.3". That's right, but there's
> more to it. The Designation Descriptor field in that Capability descriptor
> shall match the one in the RECEIVE CREDENTIAL command parameter.
>
> Comment 3:
> The requirement specified in comment 2 provides that any credential
> prepared by a Security Manager will have designation type NAA (because
> that's the only one allowed in the request). However, since the standard
> provides for self-generated credentials (see the BASIC CbCS method), I
> suggest requiring NAA in the Capability Designation Descriptor field in
> 6.19.2.3 (CbCS capability descriptor).
>
> <big snip>
I am at a loss as to how to address these two comments, based on the
following definition of the capability designation descriptor field
in 07-454r5:
"The format of the Designation descriptor field is defined by the
value of the DESIGNATION TYPE field. The size of the Designation
descriptor shall not exceed 36 bytes. If the value of the DESIGNATION
TYPE field is 2h (i.e., MAM Attribute descriptor) and the ATTRIBUTE
IDENTIFIER within the MAM Attribute contains any value other than 0401h
(MEDIUM SERIAL NUMBER), this command shall be terminated with a CHECK
CONDITION status, with the sense key set to ILLEGAL REQUEST, and the
additional sense code set to INVALID FIELD IN CDB."
If I force the capability designation descriptor to identically equal
the CDB designation descriptor, then the capability designation
descriptor does not contain a MAM attribute (and as near as I can
tell the capability stops identifying a volume).
If I attempt to put both the CDB designation descriptor and the
CDB MAM attribute into the capability designation descriptor,
the 57 bytes of necessary data overflows the 36 bytes that are
permitted by the capability format definition.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Sat Mar  8 23:00:50 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 9 Mar 2008 00:00:50 -0700
Subject: Recent T10 documents uploaded since 2008/03/02
Message-ID: <mailman.240.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAM-4 Letter Ballot comments resolution document
(by: George O. Penokie)
T10/07-478r3   Uploaded: 2008/03/04   1908991 bytes
ftp://ftp.t10.org/t10/document.07/07-478r3.pdf
SAS: Add low power transceiver options
(by: Gerald Houlder)
T10/08-015r1   Uploaded: 2008/03/03   135293 bytes
ftp://ftp.t10.org/t10/document.08/08-015r1.pdf
Proposal for SAS 2.x Specification to Enable Support for Active Cables
(by: Gourgen Oganessyan)
T10/08-052r2   Uploaded: 2008/03/07   52959 bytes
ftp://ftp.t10.org/t10/document.08/08-052r2.pdf
SMC-3, Report Element Information
(by: Curtis Ballard)
T10/08-066r2   Uploaded: 2008/03/07   150624 bytes
ftp://ftp.t10.org/t10/document.08/08-066r2.pdf
SSC-3: Revision 04a Letter Ballot Comment Database
(by: David Peterson)
T10/08-095r1   Uploaded: 2008/03/06   66906 bytes
ftp://ftp.t10.org/t10/document.08/08-095r1.pdf
SSC-3: Revision 04a Letter Ballot Comment Database
(by: David Peterson)
T10/08-095r1   Uploaded: 2008/03/06   212480 bytes
ftp://ftp.t10.org/t10/document.08/08-095r1.xls
Results of Letter Ballot on forwarding SSC-3 to first public review
(by: John Lohmeyer)
T10/08-097r0   Uploaded: 2008/03/03   429410 bytes
ftp://ftp.t10.org/t10/document.08/08-097r0.pdf
Results of Letter Ballot on forwarding SSC-3 to first public review
(by: John Lohmeyer)
T10/08-097r0   Uploaded: 2008/03/03   176505 bytes
ftp://ftp.t10.org/t10/document.08/08-097r0.txt
SPC-4: CbCS field byte alignment changes
(by: Kevin Butt)
T10/08-101r1   Uploaded: 2008/03/06   95349 bytes
ftp://ftp.t10.org/t10/document.08/08-101r1.pdf
Active Copper Cables for SAS-2.x (supporting presentation for 08-
052r2 proposal)
(by: Gourgen Oganessyan)
T10/08-103r2   Uploaded: 2008/03/07   1330730 bytes
ftp://ftp.t10.org/t10/document.08/08-103r2.pdf
ADC-3 Automation Encryption Control Corrections
(by: Curtis Ballard)
T10/08-119r0   Uploaded: 2008/03/04   54350 bytes
ftp://ftp.t10.org/t10/document.08/08-119r0.pdf
SPC-4 SBC-3 SAS-2.1 Power condition enhancements
(by: Rob Elliott)
T10/08-126r0   Uploaded: 2008/03/06   248222 bytes
ftp://ftp.t10.org/t10/document.08/08-126r0.pdf
SPC-4 RECEIVE CREDENTIAL command 'adjustments'
(by: Ralph O. Weber)
T10/08-128r0   Uploaded: 2008/03/06   56675 bytes
ftp://ftp.t10.org/t10/document.08/08-128r0.pdf
SPC-4 RECEIVE CREDENTIAL command 'adjustments'
(by: Ralph O. Weber)
T10/08-128r1   Uploaded: 2008/03/08   57995 bytes
ftp://ftp.t10.org/t10/document.08/08-128r1.pdf
SPC-4 CbCS capability validation omissions
(by: Ralph O. Weber)
T10/08-129r0   Uploaded: 2008/03/05   31380 bytes
ftp://ftp.t10.org/t10/document.08/08-129r0.pdf
SSC-3: Working Group Agenda, March 11, 2008
(by: David Peterson)
T10/08-135r0   Uploaded: 2008/03/06   8305 bytes
ftp://ftp.t10.org/t10/document.08/08-135r0.pdf
SSC-4: Project Proposal
(by: David Peterson)
T10/08-136r0   Uploaded: 2008/03/06   43569 bytes
ftp://ftp.t10.org/t10/document.08/08-136r0.pdf
FCP-4: Defects in FCP-4r00a
(by: Kevin Butt)
T10/08-137r0   Uploaded: 2008/03/07   34429 bytes
ftp://ftp.t10.org/t10/document.08/08-137r0.pdf
Constraints on SPC-4 SA creation based on Usage Type
(by: Ralph O. Weber)
T10/08-138r0   Uploaded: 2008/03/08   32179 bytes
ftp://ftp.t10.org/t10/document.08/08-138r0.pdf
Working Drafts
--------------
Automation/Drive Interface Commands - 3 (ADC-3)
(Editor: Paul Stone)
 Rev: 00a      Uploaded: 2008/03/05   1061353 bytes
ftp://ftp.t10.org/t10/drafts/adc3/adc3r00a.pdf
(Report generated on 2008/03/09 at 00:00:50)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From SIVANT at il.ibm.com  Sun Mar  9 20:16:02 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Sun, 9 Mar 2008 22:16:02 -0500
Subject: Comments on: CbCS 'correction' proposals
Message-ID: <mailman.241.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
I confirm the new revision addresses those comments, thanks.
A couple of typo/editorial:
1) In 6.19.1.2 and in 6.19.1.3 where you say "as show in" it should be "as
shown in"
2) Table x3 - the last byte shoud be at offset 55 instead of 56 (we start
counting at 0).
- Sivan.
owner-t10 at t10.org wrote on 03/08/2008 08:31:52 PM:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> Sivan Tal wrote:
> > <snip>
> >
> > Comment 4:
> > The RECEIVE CREDENTIAL command must always include a logical unit (or
SCSI
> > device) and optionally a volume designator. When CbCS is used with
volumes,
> > the Capability field only contains identification of the volume, but
the
> > request must also include identification of the LU through which the
volume
> > is to be accessed. This allows the Security Manager to use the right
shared
> > key for the ICV. The new way you constructed the CDB allows for either
LU
> > or volume identifier. It should be either LU or LU+volume.
> >
> > Comment 5:
> > In 6.19.1.3 the text "the MAM ATTRIBUTE field" should be "the
CREDENTIAL
> > REQUEST DESCRIPTOR field".
> >
> > Comment 6:
> > Table 180 ??? Capability format values : This should be renamed to
> > "Credential format values". Note that 'Credential' is what the CbCS
> > Management device server sends to the Secure CDB Originator, but the
> > Enforcement Manager never gets a 'Credential'. It only gets a
'Capability'
> > and 'ICV'. The group had decided that a 'CbCS Capability' has a single
> > format and future formats will define new capability types and
extension
> > types.
> > The rationale is that the current (only) credential format - 1h - is
used
> > in conjunction with CbCS extension. In the future, new credential
formats
> > may be defined, in conjunction with new extension types (say CbCSv2,
CbCSv3
> > type extensions). Moreover, new credential formats may be defined to
> > facilitate non-CbCS credentials, as the SCSI command security model
> > supports multiple techniques (We spent so much time on this - you
wouldn't
> > forget that ;-)
> > <snip>
> >
> Hopefully, these comments are addressed by the just uploaded:
>
> http://www.t10.org/ftp/t10/document.08/08-128r1.pdf
>
> All the best,
>
> .Ralph
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From SIVANT at il.ibm.com  Sun Mar  9 20:35:16 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Sun, 9 Mar 2008 22:35:16 -0500
Subject: Capability must contain LU designation descriptor
Message-ID: <mailman.242.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
You're right. I realize I didn't specify it correctly. Here's the right
requirement, written in my own informal words:
The returned Capability descriptor contains either a LU designation
descriptor or a MAM Attribute descriptor.
If the CREDENTIAL REQUEST TYPE field in the CDB contains 'CbCS logical unit
', then the returned Capability descriptor shall contain a LU unit
designation descriptor that matches the DESIGNATION DESCRIPTOR field in the
CREDENTIAL REQUEST DESCRIPTOR field in the CDB.
If the CREDENTIAL REQUEST TYPE field in the CDB contains 'CbCS logical unit
and volume', then the returned Capability descriptor shall contain a MAM
Attribute descriptor that matches the MAM ATTRIBUTE field in the CREDENTIAL
REQUEST DESCRIPTOR field in the CDB.
- Sivan.
	     Ralph Weber						   
	     <roweber at IEEE.org						   
	     >								To 
	     Sent by:		       "'t10 at t10.org'" <t10 at t10.org>	   
	     owner-t10 at t10.org						cc 
								   Subject 
	     03/08/2008 08:50	       Capability must contain LU	   
	     PM 		       designation descriptor		   
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Sivan Tal wrote:
> <snip>
>
> Comment 2:
> A flaw in 07-454r5 that I suggest fixing here. In 6.19.2.2 (RECEIVE
> CREDENTIAL decrypted parameter data) it says that "The contents of the
CbCS
> capability descriptor are defined in 6.19.2.3". That's right, but there's
> more to it. The Designation Descriptor field in that Capability
descriptor
> shall match the one in the RECEIVE CREDENTIAL command parameter.
>
> Comment 3:
> The requirement specified in comment 2 provides that any credential
> prepared by a Security Manager will have designation type NAA (because
> that's the only one allowed in the request). However, since the standard
> provides for self-generated credentials (see the BASIC CbCS method), I
> suggest requiring NAA in the Capability Designation Descriptor field in
> 6.19.2.3 (CbCS capability descriptor).
>
> <big snip>
I am at a loss as to how to address these two comments, based on the
following definition of the capability designation descriptor field
in 07-454r5:
"The format of the Designation descriptor field is defined by the
value of the DESIGNATION TYPE field. The size of the Designation
descriptor shall not exceed 36 bytes. If the value of the DESIGNATION
TYPE field is 2h (i.e., MAM Attribute descriptor) and the ATTRIBUTE
IDENTIFIER within the MAM Attribute contains any value other than 0401h
(MEDIUM SERIAL NUMBER), this command shall be terminated with a CHECK
CONDITION status, with the sense key set to ILLEGAL REQUEST, and the
additional sense code set to INVALID FIELD IN CDB."
If I force the capability designation descriptor to identically equal
the CDB designation descriptor, then the capability designation
descriptor does not contain a MAM attribute (and as near as I can
tell the capability stops identifying a volume).
If I attempt to put both the CDB designation descriptor and the
CDB MAM attribute into the capability designation descriptor,
the 57 bytes of necessary data overflows the 36 bytes that are
permitted by the capability format definition.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Paul.Suhler at Quantum.Com  Sun Mar  9 20:32:16 2008
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Sun, 9 Mar 2008 20:32:16 -0700
Subject: ADT-2:  Internet ADT (iADT) (07-469) [Suhler]
Message-ID: <mailman.243.1441607335.22514.t10@sandbox.t10.org>

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

I have uploaded the next revision of the iADT proposal.  It should be
available shortly on the T10 server:
http://www.t10.org/ftp/t10/document.07/07-469r1.pdf
Thanks,
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.1450 | paul.suhler at quantum.com  
___________________________________
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.  Permission
is hereby explicitly granted to disclose, copy, and further distribute to any
individual(s) or organization(s), without restriction.
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.


From roweber at IEEE.org  Mon Mar 10 03:41:25 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Mon, 10 Mar 2008 05:41:25 -0500
Subject: Capability must contain LU designation descriptor
Message-ID: <mailman.244.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The new text has been added to:
http://www.t10.org/ftp/t10/document.08/08-128r2.pdf
All the best,
.Ralph
Sivan Tal wrote:
> Ralph,
>
> You're right. I realize I didn't specify it correctly. Here's the right
> requirement, written in my own informal words:
>
> The returned Capability descriptor contains either a LU designation
> descriptor or a MAM Attribute descriptor.
> If the CREDENTIAL REQUEST TYPE field in the CDB contains 'CbCS logical unit
> ', then the returned Capability descriptor shall contain a LU unit
> designation descriptor that matches the DESIGNATION DESCRIPTOR field in the
> CREDENTIAL REQUEST DESCRIPTOR field in the CDB.
> If the CREDENTIAL REQUEST TYPE field in the CDB contains 'CbCS logical unit
> and volume', then the returned Capability descriptor shall contain a MAM
> Attribute descriptor that matches the MAM ATTRIBUTE field in the CREDENTIAL
> REQUEST DESCRIPTOR field in the CDB.
>
> - Sivan.
>   
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Mon Mar 10 03:49:03 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Mon, 10 Mar 2008 05:49:03 -0500
Subject: Comments on: CbCS 'correction' proposals
Message-ID: <mailman.245.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Sivan Tal wrote:
> I confirm the new revision addresses those comments, thanks.
>
> A couple of typo/editorial:
> 1) In 6.19.1.2 and in 6.19.1.3 where you say "as show in" it should be "as
> shown in"
>   
These corrections appear in:
http://www.t10.org/ftp/t10/document.08/08-128r2.pdf
> 2) Table x3 - the last byte shoud be at offset 55 instead of 56 (we start
> counting at 0).
>   
The problem here is that the specified MAM attribute
(0401h MEDIUM SERIAL NUMBER) has a length of 37 bytes,
specifically 32 bytes of serial number plus 5 bytes of
header.
N.B. This means a 36-byte CbCS designation descriptor
field is not large enough to hold it. (I just realized
this myself, and have not yet decided how to fix it.)
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at ieee.org  Mon Mar 10 05:17:20 2008
From: roweber at ieee.org (Ralph Weber)
Date: Mon, 10 Mar 2008 07:17:20 -0500
Subject: CbCS SECURITY PROTOCOL IN/OUT tweaks
Message-ID: <mailman.246.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Because there was no prototype to clone, a potentially
important requirement was omitted from 07-454r5.
Also, it might be useful to align the CbCS page codes
between SECURITY PROTOCOL IN and SECURITY PROTOCOL OUT.
See the details in:
http://www.t10.org/ftp/t10/document.08/08-141r0.pdf
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From curtis.ballard at hp.com  Mon Mar 10 06:37:18 2008
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Mon, 10 Mar 2008 13:37:18 +0000
Subject: SMC-3 Action Item - Use of 06h,28h,00h sense code
Message-ID: <mailman.247.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
In the SMC-3 working group meeting there was a request that companies post
information to the T10 reflector and to Geoffrey Barton regarding their use
of the NOT READY TO READY CHANGE. MEDIUM MAY HAVE CHANGED 06h,28h,00h
additional sense data.	This email is to close that action item for HP.
HP uses that sense code at power up and following any physical configuration
change that may effect inventory other than a mailslot close.
Curtis Ballard
Hewlett Packard
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From matt.ball at ieee.org  Mon Mar 10 06:40:43 2008
From: matt.ball at ieee.org (Matt Ball)
Date: Mon, 10 Mar 2008 07:40:43 -0600
Subject: IEEE P1619.3 Overview will start at 10:00 am in the Dogwood A room
Message-ID: <mailman.248.1441607335.22514.t10@sandbox.t10.org>

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

Hi all,
For those interested in an introduction to IEEE P1619.3 Key Management,
there will be a overview presentation at 10:00 a.m. in the Dogwood A room at
the Hilton.
Here is dial-in information for those who are not at T10 in person:
Topic: IEEE P1619.3
Date: Monday, March 10, 2008
Time: 10:00 am, Eastern Daylight Time (GMT -04:00, New York )
Meeting Number: 756 564 699
Meeting Password: raleigh777
Please click the link below to see more information, or to join the meeting.
-------------------------------------------------------
To join the online meeting
-------------------------------------------------------
1. Go to https://hds.webex.com/hds/j.php?ED=95772587&UID=491499402
2. Enter your name and email address.
3. Enter the meeting password: raleigh777
4. Click "Join".
-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Call-in toll-free number (US/Canada): 866-469-3239
Call-in toll number (US/Canada): 650-429-3300
Global call-in numbers:
https://hds.webex.com/hds/globalcallin.php?serviceType=MC&ED=95772587&tollFre
e=1
Toll-free dialing restrictions:
http://www.webex.com/pdf/tollfree_restrictions.pdf
-- 
Thanks!
Matt Ball, IEEE P1619.x SISWG Chair
M.V. Ball Technical Consulting, Inc.
Phone: 303-469-2469, Cell: 303-717-2717
http://www.mvballtech.com
http://www.linkedin.com/in/matthewvball


From Halvard.Eriksen at tandbergstorage.com  Mon Mar 10 06:48:10 2008
From: Halvard.Eriksen at tandbergstorage.com (Halvard Eriksen)
Date: Mon, 10 Mar 2008 14:48:10 +0100
Subject: SMC Action item, NOT READY TO READY CHANGE, MEDIUM MAY HAVE CHANGED
Message-ID: <mailman.249.1441607335.22514.t10@sandbox.t10.org>

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

To:  SMC working Group
From: Halvard Eriksen
	     Tandberg Storage asa
Date:  March 10. 2008
There is an action Item for Tandberg Storage concerning use of the Sense Code
NOT READY TO READY CHANGE, MEDIUM MAY HAVE CHANGED
I have talked to Tandberg Data Oslo and they are using this sense code in
their libraries to  indicate that a magazine is released or
Has been inserted and an inventory has been performed.
Halvard Eriksen
Tandberg Storage.


From lohmeyer at t10.org  Tue Mar 11 06:41:44 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 11 Mar 2008 07:41:44 -0600
Subject: SAS Protocol WG minutes posted
Message-ID: <mailman.250.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft minutes of the SAS Protocol working group meeting from March 10,
2008 are available at:
  http://www.t10.org/ftp/t10/document.08/08-130r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Tue Mar 11 09:11:42 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 11 Mar 2008 10:11:42 -0600
Subject: SAT-2 WG minutes posted
Message-ID: <mailman.251.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft minutes of the SAT-2 working group meeting from March 10-11, 2008
are available at:
   http://www.t10.org/ftp/t10/document.08/08-131r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From matt.ball at IEEE.org  Tue Mar 11 11:51:07 2008
From: matt.ball at IEEE.org (Matt Ball)
Date: Tue, 11 Mar 2008 12:51:07 -0600
Subject: [SSC-3] NIST changed the FIPS 140-2 Implementation Guidance to require AES Key Wrap for Symmetric Key Establishment
Message-ID: <mailman.252.1441607335.22514.t10@sandbox.t10.org>

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

Hi Tape Folks,
It looks like NIST recently changed their FIPS 140-2 Implementation Guidance
last January to require 'AES Key Wrap' as the only approved symmetric
encryption algorithm for key establishment or entry.  Previously, we
believed that using ESP was adequate for encrypting keys for entry into a
tape drive device.
To see NIST's latest guidance, look at <
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf&gt;
Also, see FIPS 140-2 Annex D "Key Establishment Techniques": <
http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexd.pdf&gt;.
Essentially, NIST is no longer allowing differentiating between the
requirements for 'Key Entry' vs. 'Key Establishment'.  It was previously
possible to argue with FIPS certification labs that this process was covered
under 'Key Entry', and the encryption of the key could use any Approved Mode
of Operation (like as used in ESP-SCSI).  For 'Key Establishment' AES Key
Wrap (not CBC, CCM, or GCM) is the only approved symmetric wrapping
algorithm.
This has an impact on SSC-3 (or SSC-4 if deferred), and will likely affect
existing tape drive products that were expecting to get FIPS 140-2 approval
by supporting IKEv2-SCSI with ESP for establishing encryption keys.
Double-check with your validation lab (your mileage may vary).
There are several ways to approach this problem.  One method will be
described in T10/08-155r0.  Another approach is to lobby NIST to change
their guidance so that existing symmetric encryption modes are sufficient
for key transport.  Yet another approach is to use the existing RSA and ECC
encryption algorithms for Key Entry, if you want to pay for an expense
asymmetric key operation each time you enter a key.
If you have received different guidance from your FIPS lab, I would be
interested in hearing different angles...
-- 
Thanks!
Matt Ball, IEEE P1619.x SISWG Chair
M.V. Ball Technical Consulting, Inc.
Phone: 303-469-2469, Cell: 303-717-2717
http://www.mvballtech.com
http://www.linkedin.com/in/matthewvball


From roweber at IEEE.org  Tue Mar 11 20:28:22 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 11 Mar 2008 22:28:22 -0500
Subject: SPC-4 r13
Message-ID: <mailman.253.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
SPC-4 r13 is available as:
http://www.t10.org/ftp/t10/drafts/spc4/spc4r13.pdf
It contains all approved proposals except 07-454r5, CbCS.
CbCS collided with the emerging SA creation and ESP plans
in ways that require some substantive changes before CbCS
will integrate in SPC-4 in a reasonable fashion.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From mikeb at bustrace.com  Wed Mar 12 10:52:50 2008
From: mikeb at bustrace.com (Mike Berhan)
Date: Wed, 12 Mar 2008 10:52:50 -0700
Subject: MMC-6 update?
Message-ID: <mailman.254.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
The last MMC-6 draft is from 20007/10/25.  Is there a new revision coming
soon?  There are some features, such as the BCA read capability (both
feature descriptor and disc structure), that are appearing in some drives
but are not documented in MMC yet.
Alternatively, does the Blu-ray Disc Association TEG5 group have a separate
web site where these specifications are available.  I realize the BCA read
capability has been uploaded as a proposal to t10, I am just wondering if
there is a central place where all the Blu-ray Disc Association TEG5
proposals can be found (or when they will be incorporated into MMC-6).
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From jgeldman at lexar.com  Wed Mar 12 19:53:49 2008
From: jgeldman at lexar.com (jgeldman at lexar.com)
Date: Wed, 12 Mar 2008 19:53:49 -0700
Subject: FW: Re: T10 Document Number Assigned (T10/08-166r0)
Message-ID: <mailman.255.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <jgeldman at lexar.com>
*
The presentation Steve McGowan made in today's T10 CAP (March 2008) on
USB protocol has been posted (without including it in the next CAP
agenda).
Regards,
John Geldman
Lexar Media
47300 Bayside Parkway
Fremont, CA 94538
P: 510 580-8715
C: 510 449-3597
-----Original Message-----
From: Administrator at scsibbs.co.lsil.com
[mailto:Administrator at scsibbs.co.lsil.com] On Behalf Of T10 Document
Administrator
Sent: Wednesday, March 12, 2008 10:39 PM
To: jgeldman
Subject: Re: Re: T10 Document Number Assigned (T10/08-166r0)
2008/03/12 20:39:13 
Your request to upload a file or files to the T10 site has been
accepted.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.08/08-166r0.pdf
Source File(s) that will be archived are:
   08-166r0.ppt will be archived as 08-166r0.ppt
Normally, the posting/archiving process takes about 30 minutes.
Please contact John Lohmeyer <lohmeyer at t10.org> should you need further
assistance.
jgeldman at lexar.com wrote:
> Date: Wed Mar 12 20:39:58 2008
> From: jgeldman at lexar.com
> To: T10 Document Administrator via web upload <docs at t10.org>
> Subject: Re: T10 Document Number Assigned (T10/08-166r0)
> 
> T10 document upload details:
> 
>   Document Number: T10/08-166r0
>	Upload Code: AC_03927cJhxuovkz7
>     Document_Date: 2008/03/12
>   Document_Author: John Geldman
>    Document_Title: MSC (USB) Command Queuing V4
>    Meeting_Agenda: none
> Document_Comments: Steve McGowan's 'MSC Command Queuing' presented in
March CAP
>      Other_Number: <none>
>	  Post_File: pdf
> 
> ## COPYRIGHT POLICY
> ## ----------------
> ##
> ## Do not submit documents containing a copyright statement ## unless 
> you add the following statement:
> ##
> ##	Permission is granted to members of INCITS, its technical
> ##	committees and their associated task groups to reproduce
> ##	this document for the purposes of INCITS standardization
> ##	activities, provided this notice is included.
> ##
> ## If you upload a copyrighted document, with or without ## this 
> statement, it will be assumed implicitly that you ## and your 
> organization have given the above permission.
> ##
> ##
> ## APPROPRIATE CONTENT
> ## -------------------
> ##
> ## Do not upload inappropriate material.  If you do, your ## files 
> will be removed and your posting privileges will ## be revoked.
> 
> Attachment Converted: "D:\T10\ATTACH\08-166r0.pdf"
> 
> Attachment Converted: "D:\T10\ATTACH\08-166r0.ppt"
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Thu Mar 13 00:25:23 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Thu, 13 Mar 2008 02:25:23 -0500
Subject: CbCS working keys vs key identifier vs master keys
Message-ID: <mailman.256.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Sivan Tal wrote:
> <big snip>
> Comments on 08-129r0
> ~~~~~~~~~~~~~~~~~~~~
> I'm fine with the changes, and I suggest another one.
> <snip>
> "If the KEY VERSION field contains 0000 0000h or
> FFFF FFFFh or a value that doesn't exist for the
> logical unit and returned in the Attributes CbCS page
> (see 6.1.5 in 07-454r5), then the validation shall
> also fail."
I apologize for taking so long to respond on this one.
Studying 07-454r5 took longer than I had hoped.
The text appears to need an additional level of
indirection from KEY VERSION (a 4-bit field) to
WORKING KEY IDENTIFIER (a 32-bit field). This is
okay. I can do it, if that is what is desired.
The text also appears to apply the Special Key
Identifiers in table 17 to Working Keys. This is
not shown in 07-454r5, and I would like confirmation
of the intent. As I read 07-454r5, table 17 applies
only to the Key Identifier associated with the
master key. Also, does the FFFF FFFEh Special
Key Identifier apply to Working Keys?
Lastly, I am wondering if 07-454 ever contemplated
invalidating a working key as an alternative to
setting it to a different value. This could be
accomplished by setting the Working Key's Key
Identifier to FFFF FFFFh.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From billmc37 at ctesc.net  Thu Mar 13 05:56:23 2008
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Thu, 13 Mar 2008 07:56:23 -0500
Subject: MMC-6 update?
Message-ID: <mailman.257.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi Mike,
Fuji7 has been working on potential changes that were fluid for some 
time and I did not wish to be caught in matching revisions, so I 
produced no MMC6 draft for some months.
Fuji7 is now firming up, so I expect to return to preparing an MMC6 
draft soon. I hope to have a new version before the May T10 week in 
Santa Clara.
Bill McFerrin
DPHI
Mike Berhan wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mike Berhan" <mikeb at bustrace.com>
> *
> The last MMC-6 draft is from 20007/10/25.  Is there a new revision coming
> soon?  There are some features, such as the BCA read capability (both
> feature descriptor and disc structure), that are appearing in some drives
> but are not documented in MMC yet.
>
> Alternatively, does the Blu-ray Disc Association TEG5 group have a separate
> web site where these specifications are available.  I realize the BCA read
> capability has been uploaded as a proposal to t10, I am just wondering if
> there is a central place where all the Blu-ray Disc Association TEG5
> proposals can be found (or when they will be incorporated into MMC-6).
>
> -------
> Mike Berhan
> busTRACE Technologies
> 9700 Village Center Drive
> Suite 50-F
> Granite Bay, CA  95746
> 916.773.4554 phone
> 916.218.6283 fax
> http://www.bustrace.com
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>   
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Thu Mar 13 08:24:47 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 13 Mar 2008 08:24:47 -0700
Subject: Late Letter Ballot comment against SSC-3
Message-ID: <mailman.258.1441607335.22514.t10@sandbox.t10.org>

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

Dave,
Please add the following late letter ballot comment:
In CAP working group, the format of the permission's bit table that came 
in with the CbCS proposal (Table 20 ? Association between commands and 
CbCS permissions on physical page 68) was changed (see 08-145r1).  That 
formatting change needs to be carried into SSC-3.  The change is to change 
the 'v' to a '1' and add footnotes describing what a blank is.
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


From Gabriel.Romero at lsi.com  Thu Mar 13 08:16:30 2008
From: Gabriel.Romero at lsi.com (Romero, Gabriel)
Date: Thu, 13 Mar 2008 09:16:30 -0600
Subject: Typo in specification
Message-ID: <mailman.259.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Romero, Gabriel" <Gabriel.Romero at lsi.com>
*
It appears that there is a typo in the SAS specification revision 14
page 237 table 95. Note i calls out 2200 OOBI at 1466.6uS. I believe
this should be 1466.6nS.
Best regards,
Gabe
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Thu Mar 13 19:04:48 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 13 Mar 2008 20:04:48 -0600
Subject: CAP working group minutes posted
Message-ID: <mailman.260.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft minutes of the CAP working group meeting from March 12-13, 2008 are
available at:
   http://www.t10.org/ftp/t10/document.08/08-132r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From SIVANT at il.ibm.com  Thu Mar 13 20:21:27 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Thu, 13 Mar 2008 21:21:27 -0600
Subject: CbCS working keys vs key identifier vs master keys
Message-ID: <mailman.261.1441607335.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
See my responses below.
Regards, Sivan.
owner-t10 at t10.org wrote on 03/13/2008 02:25:23 AM:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> Sivan Tal wrote:
> > <big snip>
> > Comments on 08-129r0
> > ~~~~~~~~~~~~~~~~~~~~
> > I'm fine with the changes, and I suggest another one.
> > <snip>
> > "If the KEY VERSION field contains 0000 0000h or
> > FFFF FFFFh or a value that doesn't exist for the
> > logical unit and returned in the Attributes CbCS page
> > (see 6.1.5 in 07-454r5), then the validation shall
> > also fail."
> I apologize for taking so long to respond on this one.
> Studying 07-454r5 took longer than I had hoped.
>
> The text appears to need an additional level of
> indirection from KEY VERSION (a 4-bit field) to
> WORKING KEY IDENTIFIER (a 32-bit field). This is
> okay. I can do it, if that is what is desired.
>
Yes, that's what is desired. Thanks.
> The text also appears to apply the Special Key
> Identifiers in table 17 to Working Keys. This is
> not shown in 07-454r5, and I would like confirmation
> of the intent. As I read 07-454r5, table 17 applies
> only to the Key Identifier associated with the
> master key. Also, does the FFFF FFFEh Special
> Key Identifier apply to Working Keys?
>
0000 0000h A shared key that was never set or was invalidated
--> This applies to working keys. However, as the text above table 17
specifies, a master key identifier shall never be set to that value. So
it's safe to fail a command based on that key identifier value.
FFFF FFFEh An initial shared key set by the device server
--> This applies only to master keys. There are no initial Working keys
(the initial value for working key identifiers is 0000 0000h). However,
this could be valid when the ICV is based on the master key (e.g. in those
commands that manipulate keys) so validation should pass on that value.
FFFF FFFFh Pertinent shared key is not supported by the device server
--> This should be used in the Attributes CbCS page of SECURITY PROTOCOL IN
to denote a keys that are not supported by the LU or by the device. It
should never appear in a Capability.
> Lastly, I am wondering if 07-454 ever contemplated
> invalidating a working key as an alternative to
> setting it to a different value. This could be
> accomplished by setting the Working Key's Key
> Identifier to FFFF FFFFh.
>
Setting key identifier to 0000 0000h effectively invalidates the key.
A key identifier should never be set to FFFF FFFFh. This value denotes keys
are not supported for the LU or device. For instance, if a device only
supports a global set of keys that are used for all its LUs, then the
Attributes CbCS page for any LU (other than well-known LU that represent
the device) contains that value in the key identifier fields.
I believe this is a CbCS thing that OSD doesn't have.
> All the best,
>
> .Ralph
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Sat Mar 15 23:00:51 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 16 Mar 2008 00:00:51 -0600
Subject: Recent T10 documents uploaded since 2008/03/08
Message-ID: <mailman.262.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAT-2: ATAPI Translation
(by: Mark A. Overby)
T10/07-328r1   Uploaded: 2008/03/10   68259 bytes
ftp://ftp.t10.org/t10/document.07/07-328r1.pdf
SAT-2: ATAPI Translation
(by: Mark A. Overby)
T10/07-328r2   Uploaded: 2008/03/10   68773 bytes
ftp://ftp.t10.org/t10/document.07/07-328r2.pdf
ADT-2:	Internet ADT (iADT)
(by: Paul Suhler)
T10/07-469r1   Uploaded: 2008/03/09   59698 bytes
ftp://ftp.t10.org/t10/document.07/07-469r1.pdf
SAT-2 Additional power management methods
(by: Frederick Knight)
T10/07-485r3   Uploaded: 2008/03/10   104533 bytes
ftp://ftp.t10.org/t10/document.07/07-485r3.pdf
SPC-4 Download microcode I_T nexus usage
(by: Rob Elliott)
T10/08-008r1   Uploaded: 2008/03/10   40004 bytes
ftp://ftp.t10.org/t10/document.08/08-008r1.pdf
SPC-4 Download microcode I_T nexus usage
(by: Rob Elliott)
T10/08-008r2   Uploaded: 2008/03/13   41337 bytes
ftp://ftp.t10.org/t10/document.08/08-008r2.pdf
SAT-2 WRITE BUFFER MODE 7 to DOWNLOAD MICROCODE Mode 3
(by: Jeff Wolford)
T10/08-019r1   Uploaded: 2008/03/09   35461 bytes
ftp://ftp.t10.org/t10/document.08/08-019r1.pdf
SAT-2 WRITE BUFFER MODE 7 to DOWNLOAD MICROCODE Mode 3
(by: Jeff Wolford)
T10/08-019r2   Uploaded: 2008/03/11   38979 bytes
ftp://ftp.t10.org/t10/document.08/08-019r2.pdf
SAT-2: Work Items and Open Issues List
(by: Mark A. Overby)
T10/08-023r2   Uploaded: 2008/03/10   33454 bytes
ftp://ftp.t10.org/t10/document.08/08-023r2.pdf
Minutes: ADI Meeting 14 January 2008
(by: Michael Banther)
T10/08-042r2   Uploaded: 2008/03/11   31696 bytes
ftp://ftp.t10.org/t10/document.08/08-042r2.pdf
T13 Liaison Report March 08
(by: Dan Colegrove)
T10/08-087r1   Uploaded: 2008/03/13   10222 bytes
ftp://ftp.t10.org/t10/document.08/08-087r1.pdf
SPC-4 UML Conventions and CbCS UML Updates
(by: Ralph O. Weber)
T10/08-113r2   Uploaded: 2008/03/14   63667 bytes
ftp://ftp.t10.org/t10/document.08/08-113r2.pdf
SBC-3 SPC-4: Protection Type 3 Reference Tag Clarification
(by: George Penokie)
T10/08-116r1   Uploaded: 2008/03/13   156754 bytes
ftp://ftp.t10.org/t10/document.08/08-116r1.pdf
Project Proposal: SCSI Architecture Model - 5 (SAM-5)
(by: George Penokie)
T10/08-124r1   Uploaded: 2008/03/12   67257 bytes
ftp://ftp.t10.org/t10/document.08/08-124r1.pdf
FCP-4: FC-4 Features object and device type support
(by: David Peterson)
T10/08-127r0   Uploaded: 2008/03/10   13049 bytes
ftp://ftp.t10.org/t10/document.08/08-127r0.pdf
SPC-4 RECEIVE CREDENTIAL command 'adjustments'
(by: Ralph O. Weber)
T10/08-128r1   Uploaded: 2008/03/08   57995 bytes
ftp://ftp.t10.org/t10/document.08/08-128r1.pdf
SPC-4 RECEIVE CREDENTIAL command 'adjustments'
(by: Ralph O. Weber)
T10/08-128r2   Uploaded: 2008/03/10   60263 bytes
ftp://ftp.t10.org/t10/document.08/08-128r2.pdf
Minutes of SAS Protocol Working Group - March 10 2008
(by: Weber & Lohmeyer)
T10/08-130r0   Uploaded: 2008/03/11   34305 bytes
ftp://ftp.t10.org/t10/document.08/08-130r0.htm
Minutes of SAS Protocol Working Group - March 10 2008
(by: Weber & Lohmeyer)
T10/08-130r0   Uploaded: 2008/03/11   103241 bytes
ftp://ftp.t10.org/t10/document.08/08-130r0.pdf
Minutes of SAT-2 Working Group - March 10-11 2008
(by: Lohmeyer & Overby)
T10/08-131r0   Uploaded: 2008/03/11   33202 bytes
ftp://ftp.t10.org/t10/document.08/08-131r0.htm
Minutes of SAT-2 Working Group - March 10-11 2008
(by: Lohmeyer & Overby)
T10/08-131r0   Uploaded: 2008/03/11   100228 bytes
ftp://ftp.t10.org/t10/document.08/08-131r0.pdf
Minutes of CAP Working Group - March 12-13 2008
(by: Weber & Lohmeyer)
T10/08-132r0   Uploaded: 2008/03/13   57524 bytes
ftp://ftp.t10.org/t10/document.08/08-132r0.htm
Minutes of CAP Working Group - March 12-13 2008
(by: Weber & Lohmeyer)
T10/08-132r0   Uploaded: 2008/03/13   144960 bytes
ftp://ftp.t10.org/t10/document.08/08-132r0.pdf
FCP-4: Working Group Agenda, March 11, 2008
(by: David Peterson)
T10/08-134r0   Uploaded: 2008/03/10   6792 bytes
ftp://ftp.t10.org/t10/document.08/08-134r0.pdf
Constraints on SPC-4 SA creation based on Usage Type
(by: Ralph O. Weber)
T10/08-138r0   Uploaded: 2008/03/08   32179 bytes
ftp://ftp.t10.org/t10/document.08/08-138r0.pdf
Constraints on SPC-4 SA creation based on Usage Type
(by: Ralph O. Weber)
T10/08-138r1   Uploaded: 2008/03/14   31925 bytes
ftp://ftp.t10.org/t10/document.08/08-138r1.pdf
SBC - START/STOP command additions
(by: Frederick Knight)
T10/08-139r0   Uploaded: 2008/03/10   45247 bytes
ftp://ftp.t10.org/t10/document.08/08-139r0.pdf
SBC - START/STOP command additions
(by: Frederick Knight)
T10/08-139r1   Uploaded: 2008/03/13   44874 bytes
ftp://ftp.t10.org/t10/document.08/08-139r1.pdf
ADC-3: Potential security hole in automation encryption control
(by: Curtis Ballard)
T10/08-140r0   Uploaded: 2008/03/09   49402 bytes
ftp://ftp.t10.org/t10/document.08/08-140r0.pdf
CbCS SECURITY PROTOCOL IN/OUT tweaks in SPC-4
(by: Ralph O. Weber)
T10/08-141r0   Uploaded: 2008/03/10   31975 bytes
ftp://ftp.t10.org/t10/document.08/08-141r0.pdf
Minutes: SMC-3 WG 10 Mar 2008
(by: Kevin Butt)
T10/08-142r0   Uploaded: 2008/03/10   32054 bytes
ftp://ftp.t10.org/t10/document.08/08-142r0.pdf
Request for a waiver from INCITS RD-1 clause 3.2
(by: John Lohmeyer)
T10/08-143r0   Uploaded: 2008/03/13   51811 bytes
ftp://ftp.t10.org/t10/document.08/08-143r0.pdf
Comments on SAS2r14 Physical Layer
(by: Kevin Witt)
T10/08-144r0   Uploaded: 2008/03/10   636834 bytes
ftp://ftp.t10.org/t10/document.08/08-144r0.pdf
Capability-based Command Security (CbCS) [the rewrite]
(by: Ralph O. Weber)
T10/08-145r0   Uploaded: 2008/03/12   112169 bytes
ftp://ftp.t10.org/t10/document.08/08-145r0.pdf
Proposed Changes to Receiver Device Physical Testing  Section in SAS
2 Draft
(by: Michael Jenkins)
T10/08-146r0   Uploaded: 2008/03/11   117700 bytes
ftp://ftp.t10.org/t10/document.08/08-146r0.pdf
ADI: Features for ADC-3 and ADT-3
(by: Paul Suhler)
T10/08-147r0   Uploaded: 2008/03/11   35690 bytes
ftp://ftp.t10.org/t10/document.08/08-147r0.pdf
ADI-2 Working Group Report to Plenary, March 2008
(by: Paul Suhler)
T10/08-150r0   Uploaded: 2008/03/12   12227 bytes
ftp://ftp.t10.org/t10/document.08/08-150r0.pdf
ADI-2 Working Group Report to Plenary, March 2008
(by: Paul Suhler)
T10/08-150r1   Uploaded: 2008/03/12   13891 bytes
ftp://ftp.t10.org/t10/document.08/08-150r1.pdf
Minutes of ADI Protocol Working Group - March 10 2008
(by: Curtis Ballard)
T10/08-151r0   Uploaded: 2008/03/12   42390 bytes
ftp://ftp.t10.org/t10/document.08/08-151r0.pdf
Minutes of ADI Protocol Working Group - March 10 2008
(by: Curtis Ballard)
T10/08-151r1   Uploaded: 2008/03/12   42621 bytes
ftp://ftp.t10.org/t10/document.08/08-151r1.pdf
SMC-3 Working Group Report to Plenary, March 2008
(by: Curtis Ballard)
T10/08-152r0   Uploaded: 2008/03/13   13188 bytes
ftp://ftp.t10.org/t10/document.08/08-152r0.pdf
Minutes of FCP-4 Working Group - March 11 2008
(by: Bob Nixon)
T10/08-153r0   Uploaded: 2008/03/11   24893 bytes
ftp://ftp.t10.org/t10/document.08/08-153r0.pdf
Minutes: SSC-3 WG 11 March 2008
(by: Kevin Butt)
T10/08-154r0   Uploaded: 2008/03/12   48891 bytes
ftp://ftp.t10.org/t10/document.08/08-154r0.pdf
Minutes: SSC-3 WG 11 March 2008
(by: Kevin Butt)
T10/08-154r1   Uploaded: 2008/03/13   49407 bytes
ftp://ftp.t10.org/t10/document.08/08-154r1.pdf
SBC-3 SPC-4: Non-volatile cache becoming volatile
(by: George Penokie)
T10/08-156r0   Uploaded: 2008/03/12   65671 bytes
ftp://ftp.t10.org/t10/document.08/08-156r0.pdf
SBC-3 SPC-4: Non-volatile cache becoming volatile
(by: George Penokie)
T10/08-156r1   Uploaded: 2008/03/13   66074 bytes
ftp://ftp.t10.org/t10/document.08/08-156r1.pdf
Minutes: SAS PHY Working Group Minutes, March 11, 2008
(by: Alvin Cox)
T10/08-157r0   Uploaded: 2008/03/11   28518 bytes
ftp://ftp.t10.org/t10/document.08/08-157r0.pdf
SPC-4 ESP-SCSI field alignments
(by: Ralph O. Weber)
T10/08-158r0   Uploaded: 2008/03/12   42659 bytes
ftp://ftp.t10.org/t10/document.08/08-158r0.pdf
SPC-4 ESP-SCSI field alignments
(by: Ralph O. Weber)
T10/08-158r1   Uploaded: 2008/03/13   46160 bytes
ftp://ftp.t10.org/t10/document.08/08-158r1.pdf
STA: Beyond SAS 2.0 March 08
(by: Harry Mason)
T10/08-159r0   Uploaded: 2008/03/12   318017 bytes
ftp://ftp.t10.org/t10/document.08/08-159r0.pdf
STA: Molex Connector Proposals for SAS 2.x
(by: Jay Neer)
T10/08-160r0   Uploaded: 2008/03/12   1616415 bytes
ftp://ftp.t10.org/t10/document.08/08-160r0.pdf
STA: Green Features for SCSI
(by: Marty Czekalski)
T10/08-161r0   Uploaded: 2008/03/12   486757 bytes
ftp://ftp.t10.org/t10/document.08/08-161r0.pdf
STA:Future Directions of SAS Following SAS 2.0
(by: Martin, Hoffman, Kompella, Sawyer& Jones)
T10/08-162r0   Uploaded: 2008/03/12   140207 bytes
ftp://ftp.t10.org/t10/document.08/08-162r0.pdf
STA:SAS-2.1 and SAS-3 Features for consideration
(by: Tim Symons)
T10/08-163r0   Uploaded: 2008/03/12   212893 bytes
ftp://ftp.t10.org/t10/document.08/08-163r0.pdf
STA:Active Copper Cables for SAS-2.x Part Deux
(by: Gourgen Oganessyan)
T10/08-164r0   Uploaded: 2008/03/12   1363687 bytes
ftp://ftp.t10.org/t10/document.08/08-164r0.pdf
STA:Tyco Electronics prroposal for High Density Mini-SAS Connector
System
(by: Michael Fogg)
T10/08-165r0   Uploaded: 2008/03/12   453032 bytes
ftp://ftp.t10.org/t10/document.08/08-165r0.pdf
MSC (USB) Command Queuing V4
(by: John Geldman)
T10/08-166r0   Uploaded: 2008/03/12   71811 bytes
ftp://ftp.t10.org/t10/document.08/08-166r0.pdf
FCP-4: Status Report, March 13, 2008
(by: David Peterson)
T10/08-169r0   Uploaded: 2008/03/13   12612 bytes
ftp://ftp.t10.org/t10/document.08/08-169r0.pdf
SSC-3: Status Report, March 13, 2008
(by: David Peterson)
T10/08-170r0   Uploaded: 2008/03/13   7795 bytes
ftp://ftp.t10.org/t10/document.08/08-170r0.pdf
STA -T10 Liaison Report - March 13, 2008
(by: Marty Czekalski)
T10/08-171r0   Uploaded: 2008/03/13   177694 bytes
ftp://ftp.t10.org/t10/document.08/08-171r0.pdf
Minutes: MMC WG Meeting Minutes, 12 March 2008
(by: William McFerrin)
T10/08-172r0   Uploaded: 2008/03/13   12566 bytes
ftp://ftp.t10.org/t10/document.08/08-172r0.pdf
Agenda for T10 Meeting #85 May 2008
(by: John Lohmeyer)
T10/08-174r0   Uploaded: 2008/03/14   62074 bytes
ftp://ftp.t10.org/t10/document.08/08-174r0.pdf
Bogus Sense Key in SPC-4 SA Creation Parameter Data Error Handling
(by: Ralph O. Weber)
T10/08-177r0   Uploaded: 2008/03/14   29916 bytes
ftp://ftp.t10.org/t10/document.08/08-177r0.pdf
IKEv2-SCSI Message ID field size correction
(by: Ralph O. Weber)
T10/08-178r0   Uploaded: 2008/03/14   25223 bytes
ftp://ftp.t10.org/t10/document.08/08-178r0.pdf
Working Drafts
--------------
SCSI / ATA Translation - 2 (SAT-2)
(Editor: Mark Overby)
 Rev: 02a      Uploaded: 2008/03/10   1105118 bytes
ftp://ftp.t10.org/t10/drafts/sat2/sat2r02a.pdf
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 13       Uploaded: 2008/03/11   6774635 bytes
ftp://ftp.t10.org/t10/drafts/spc4/spc4r13.pdf
(Report generated on 2008/03/16 at 00:00:51)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Sun Mar 16 22:14:33 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 17 Mar 2008 14:14:33 +0900
Subject: Posted: Draft Meeting Minutes and delivered documents
Message-ID: <mailman.263.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted Draft Meeting Minutes and delivered documents on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Mar08
 Write speed characteristics - analysis.ppt
 Minimum Throughput(voted).pdf
ftp.avc-pioneer.com/Mtfuji_7/Minutes
 MinFeb08.pdf
 DraftMinMar08.pdf
Next meeting will be held on April 15 (Tue)-16 (Wed) at Hotel Shilla Seoul,
Korea hosted by TSST Korea
 http://www.shilla.net/seoul/en/about/location01.jsp
 http://www.shilla.net/seoul/jp/about/location01.jsp
 Address: 202 Jangchung-dong 2-ga, Jung-gu, Seoul 100-856 Korea
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Mon Mar 17 13:29:47 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 17 Mar 2008 14:29:47 -0600
Subject: Fwd: SAS Solutions Open House invitation to T10 members
Message-ID: <mailman.264.1441607336.22514.t10@sandbox.t10.org>

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

Forwarded to T10 Reflector for Alice Tate <alice at scsita.org>.
>All T10 Members:
>
>You are cordially invited to the SCSI Trade Association's 
>SAS Solutions Open House
>
>Date:	Tuesday, May 6, 2008
>Time: 6:30 - 9:30 PM
>Place: Fairmont Hotel, San Jose, CA
>
>Some of you may remember a similar event two years ago. We will have
industry presentations, live demos, SAS market data, and wonderful food &
drink. This event is free, but you MUST register! Space is limited, and
registrations will be cut off when we have reached capacity.
>To register, go to:
><http://www.scsita">http://www.scsita.org/news_events/SAS_OpenHouse_Reg.html>http://www.scsita.
org/news_events/SAS_OpenHouse_Reg.html
>
>We will have a bus from the Hotel Valencia (T10 meeting site) to this event
at the Fairmont Hotel. If you would like to reserve a spot on the bus, first
make sure you register for the event, then email
alice at scsita.org that you would like to be on this
bus. The bus option is open only to T10 members, so will not be publicized on
the public registration web page.
>
>See you there!
>
>If you have any questions or concerns, please email Alice Tate
(alice at scsita.org)


From Elliott at hp.com  Mon Mar 17 15:16:57 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Mon, 17 Mar 2008 22:16:57 +0000
Subject: Stateye results with 850 mV and DJ=0.1
Message-ID: <mailman.265.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
Here are the Stateye v5.080111 results on all channels with these settings
(as discussed in last week's SAS Physical WG meeting):
amp=850 mV
deemp=2 dB
dfe=3 taps
DJ=0.10
RJ=0.15/14
6 Gbps
8b10b
All channels pass if the requirement for the statistical eye is:
amplitude >= 84 mV
jitter <= 0.6 UI
So, these values will be proposed as a SAS-2 letter ballot comment.
SAS2_transmittertestload.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.084
  0.6
MiniSAS_0.5meter_A5A6B5B6.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.526
  0.3
MiniSAS_1meter_A5A6B5B6.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9 0.446	0.33
MiniSAS_3meter_A5A6B5B6.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9 0.362	0.36
MiniSAS_6meter_A5A6B5B6.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9 0.226	0.42
HP01_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.28	0.39
HP02_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.302	0.38
HP03_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.334	0.34
HP04_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.358	0.35
HP05_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.332	0.37
HP06_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.248	0.38
HP07_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.298	0.36
HP08_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.274	0.38
HP09_BtoB_4Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.212	0.46
HP10_BtoB_4Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.14	0.53
HP11_BtoB_4Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.188	0.48
HP12_Brd_1mCable_Bp_Drive.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.318
  0.38
HP13_Brd_6inCable_Bp_Drive.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9 0.346 0.35
HP14_6inCable_Bp_Drive.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.266	0.38
HP24_BtoB_4Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.122	0.56
HP25_BtoB_4Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.12	0.55
HP26_BtoB_4Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.156	0.54
HP27_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.21	0.44
HP28_BtoB_3Connector.s4p_amp0.85_deemp2_dfe3_8b10b_baud6.0e9	0.222	0.4
---
Rob Elliott (elliott at hp.com)
HP Industry Standard Server Storage Advanced Technology
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Mon Mar 17 17:55:39 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Mon, 17 Mar 2008 19:55:39 -0500
Subject: SPC-4 r14 is available
Message-ID: <mailman.266.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The SPC-4 revision containing all approved documents from
the March meeting week can be found at:
http://www.t10.org/ftp/t10/drafts/spc4/spc4r14.pdf
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Tue Mar 18 01:25:39 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 18 Mar 2008 17:25:39 +0900
Subject: Posted: Fuji7r099_diff.pdf
Message-ID: <mailman.267.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted Rev. 0.99 on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Spec/FUJI7r099_diff.zip
Please send any comments to reflector or me.
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From SIVANT at il.ibm.com  Tue Mar 18 11:47:15 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Tue, 18 Mar 2008 12:47:15 -0600
Subject: Comments on: CbCS 'correction' proposals
Message-ID: <mailman.268.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
That makes the RECEIVE CREDENTIAL CDB a potentially odd length CDB.
If you append a single reserved byte at the end of 'Table x6 ??? CbCS logical
unit and volume credential request descriptor' (in 08-145r0) it makes the
CDB even length, and also aligns the Capability descriptor to be even
length.
This is just one way to deal with it, assuming odd length CDB is not
welcome.
- Sivan.
	     Ralph Weber						   
	     <roweber at IEEE.org						   
	     >								To 
	     Sent by:		       "'t10 at t10.org'" <t10 at t10.org>	   
	     owner-t10 at t10.org						cc 
								   Subject 
	     03/10/2008 06:49	       Re: Comments on: CbCS 'correction'  
	     AM 		       proposals			   
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Sivan Tal wrote:
> I confirm the new revision addresses those comments, thanks.
>
> A couple of typo/editorial:
> 1) In 6.19.1.2 and in 6.19.1.3 where you say "as show in" it should be
"as
> shown in"
>
These corrections appear in:
http://www.t10.org/ftp/t10/document.08/08-128r2.pdf
> 2) Table x3 - the last byte shoud be at offset 55 instead of 56 (we start
> counting at 0).
>
The problem here is that the specified MAM attribute
(0401h MEDIUM SERIAL NUMBER) has a length of 37 bytes,
specifically 32 bytes of serial number plus 5 bytes of
header.
N.B. This means a 36-byte CbCS designation descriptor
field is not large enough to hold it. (I just realized
this myself, and have not yet decided how to fix it.)
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From George.Penokie at lsi.com  Tue Mar 18 12:25:36 2008
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 18 Mar 2008 13:25:36 -0600
Subject: Comments on: CbCS 'correction' proposals
Message-ID: <mailman.269.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Penokie, George" <George.Penokie at lsi.com>
*
Ralph,
I seem to remember saying in the meeting last week that we decided we
were going to make the MAM thing an even byte count. Or am I thinking of
a different odd byte thing.
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Sivan
Tal
Sent: Tuesday, March 18, 2008 1:47 PM
To: Ralph Weber
Cc: owner-t10 at t10.org; 't10 at t10.org'
Subject: Re: Comments on: CbCS 'correction' proposals
* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
That makes the RECEIVE CREDENTIAL CDB a potentially odd length CDB.
If you append a single reserved byte at the end of 'Table x6 - CbCS
logical unit and volume credential request descriptor' (in 08-145r0) it
makes the CDB even length, and also aligns the Capability descriptor to
be even length.
This is just one way to deal with it, assuming odd length CDB is not
welcome.
- Sivan.
	     Ralph Weber
	     <roweber at IEEE.org
	     >
To 
	     Sent by:		       "'t10 at t10.org'" <t10 at t10.org>
	     owner-t10 at t10.org
cc 
Subject 
	     03/10/2008 06:49	       Re: Comments on: CbCS
'correction'  
	     AM 		       proposals
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Sivan Tal wrote:
> I confirm the new revision addresses those comments, thanks.
>
> A couple of typo/editorial:
> 1) In 6.19.1.2 and in 6.19.1.3 where you say "as show in" it should be
"as
> shown in"
>
These corrections appear in:
http://www.t10.org/ftp/t10/document.08/08-128r2.pdf
> 2) Table x3 - the last byte shoud be at offset 55 instead of 56 (we 
> start counting at 0).
>
The problem here is that the specified MAM attribute (0401h MEDIUM
SERIAL NUMBER) has a length of 37 bytes, specifically 32 bytes of serial
number plus 5 bytes of header.
N.B. This means a 36-byte CbCS designation descriptor field is not large
enough to hold it. (I just realized this myself, and have not yet
decided how to fix it.)
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Tue Mar 18 18:31:37 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 18 Mar 2008 20:31:37 -0500
Subject: Comments on: CbCS 'correction' proposals
Message-ID: <mailman.270.1441607336.22514.t10@sandbox.t10.org>

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

Sivan, George,
Yes, I believe we agreed to effectively make the descriptor
byte count even by adding a reserved byte.
I am still pondering whether to add the byte inside
or outside the descriptor ... with outside meaning
in the CDB definition and in the Capability definition.
I am concerned that the Capability format does not
include a Format Type field. Instead, this is in
the Credential (which means it is not a part of
the Extended CDB Descriptor definition).
The presence of a reserved byte in the Capability
tempts me to use it (or a nibble of it) for the
Capability format. I need to wrestle with this
before solidifying my inside/outside position.
All the best,
.Ralph
Penokie, George wrote:
> Ralph,
>  
> I seem to remember saying in the meeting last week that we decided we
> were going to make the MAM thing an even byte count. Or am I thinking of
> a different odd byte thing.
>
> Bye for now, 
> George Penokie
>  
> LSI Corporation 
> 3033 41st St. NW 
> Suite 100 
> Rochester, MN 55901
>  
> 507-328-9017 
> george.penokie at lsi.com
>
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Sivan
> Tal
> Sent: Tuesday, March 18, 2008 1:47 PM
> To: Ralph Weber
> Cc: owner-t10 at t10.org; 't10 at t10.org'
> Subject: Re: Comments on: CbCS 'correction' proposals
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Sivan Tal <SIVANT at il.ibm.com>
> *
> Ralph,
>
> That makes the RECEIVE CREDENTIAL CDB a potentially odd length CDB.
>
> If you append a single reserved byte at the end of 'Table x6 - CbCS
> logical unit and volume credential request descriptor' (in 08-145r0) it
> makes the CDB even length, and also aligns the Capability descriptor to
> be even length.
> This is just one way to deal with it, assuming odd length CDB is not
> welcome.
>
> - Sivan.
>
>
>
>  
>
>	       Ralph Weber
>
>	       <roweber at IEEE.org
>
>	       >
> To 
>	       Sent by: 		 "'t10 at t10.org'" <t10 at t10.org>
>
>	       owner-t10 at t10.org
> cc 
>  
>
>  
> Subject 
>	       03/10/2008 06:49 	 Re: Comments on: CbCS
> 'correction'	
>	       AM			 proposals
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> Sivan Tal wrote:
>   
>> I confirm the new revision addresses those comments, thanks.
>>
>> A couple of typo/editorial:
>> 1) In 6.19.1.2 and in 6.19.1.3 where you say "as show in" it should be
>>     
> "as
>   
>> shown in"
>>
>>     
> These corrections appear in:
>
> http://www.t10.org/ftp/t10/document.08/08-128r2.pdf
>   
>> 2) Table x3 - the last byte shoud be at offset 55 instead of 56 (we 
>> start counting at 0).
>>
>>     
> The problem here is that the specified MAM attribute (0401h MEDIUM
> SERIAL NUMBER) has a length of 37 bytes, specifically 32 bytes of serial
> number plus 5 bytes of header.
>
> N.B. This means a 36-byte CbCS designation descriptor field is not large
> enough to hold it. (I just realized this myself, and have not yet
> decided how to fix it.)
>
> All the best,
>
> .Ralph
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
>   


From SIVANT at il.ibm.com  Tue Mar 18 20:17:31 2008
From: SIVANT at il.ibm.com (Sivan Tal)
Date: Tue, 18 Mar 2008 21:17:31 -0600
Subject: Comments on: CbCS 'correction' proposals
Message-ID: <mailman.271.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sivan Tal <SIVANT at il.ibm.com>
*
Ralph,
As you're at it... here are some thoughts we have went through...
There is a DESIGNATION DESCRIPTOR field that holds wither LU/device
identifier or MAM attribute. That one should stay even size, so I don't see
exactly how you add the extra byte at the top level of the capability
descriptor.
Note that we currently use 4 bits for DESIGNATION TYPE. But we only have
two types, and there's a good chance we'll never need more than four, so 2
bits may be enough, and the other 2 bits can be used to encode four
different capability formats.
We used to have a capability format field in early revisions, and we
removed it to save space. The capability format is effectively specified
outside the capability - in the XCDB extension type. The idea is that a new
capability format would be added via a new CDB extension type. Not such a
bad idea after all...
Regards, Sivan.
	     Ralph Weber						   
	     <roweber at IEEE.org						   
	     >								To 
	     Sent by:		       t10 at t10.org			   
	     owner-t10 at t10.org						cc 
								   Subject 
	     03/18/2008 09:31	       Re: Comments on: CbCS 'correction'  
	     PM 		       proposals			   
Sivan, George,
Yes, I believe we agreed to effectively make the descriptor
byte count even by adding a reserved byte.
I am still pondering whether to add the byte inside
or outside the descriptor ... with outside meaning
in the CDB definition and in the Capability definition.
I am concerned that the Capability format does not
include a Format Type field. Instead, this is in
the Credential (which means it is not a part of
the Extended CDB Descriptor definition).
The presence of a reserved byte in the Capability
tempts me to use it (or a nibble of it) for the
Capability format. I need to wrestle with this
before solidifying my inside/outside position.
All the best,
.Ralph
Penokie, George wrote:
      Ralph,
      I seem to remember saying in the meeting last week that we decided we
      were going to make the MAM thing an even byte count. Or am I thinking
      of
      a different odd byte thing.
      Bye for now,
      George Penokie
      LSI Corporation
      3033 41st St. NW
      Suite 100
      Rochester, MN 55901
      507-328-9017
      george.penokie at lsi.com
      -----Original Message-----
      From: owner-t10 at t10.org [mailto:owner-t10 at t10.org.] On Behalf Of
      Sivan
      Tal
      Sent: Tuesday, March 18, 2008 1:47 PM
      To: Ralph Weber
      Cc: owner-t10 at t10.org; 't10 at t10.org'
      Subject: Re: Comments on: CbCS 'correction' proposals
      * From the T10 Reflector (t10 at t10.org), posted by:
      * Sivan Tal <SIVANT at il.ibm.com>
      *
      Ralph,
      That makes the RECEIVE CREDENTIAL CDB a potentially odd length CDB.
      If you append a single reserved byte at the end of 'Table x6 - CbCS
      logical unit and volume credential request descriptor' (in 08-145r0)
      it
      makes the CDB even length, and also aligns the Capability descriptor
      to
      be even length.
      This is just one way to deal with it, assuming odd length CDB is not
      welcome.
      - Sivan.
		   Ralph Weber
		   <roweber at IEEE.org
		   >
      To
		   Sent by:		     "'t10 at t10.org'" <t10 at t10.org>
		   owner-t10 at t10.org
      cc
      Subject
		   03/10/2008 06:49	     Re: Comments on: CbCS
      'correction'
		   AM			     proposals
      * From the T10 Reflector (t10 at t10.org), posted by:
      * Ralph Weber <roweber at ieee.org>
      *
      Sivan Tal wrote:
	    I confirm the new revision addresses those comments, thanks.
	    A couple of typo/editorial:
	    1) In 6.19.1.2 and in 6.19.1.3 where you say "as show in" it
	    should be
      "as
	    shown in"
      These corrections appear in:
      http://www.t10.org/ftp/t10/document.08/08-128r2.pdf.
	    2) Table x3 - the last byte shoud be at offset 55 instead of 56
	    (we
	    start counting at 0).
      The problem here is that the specified MAM attribute (0401h MEDIUM
      SERIAL NUMBER) has a length of 37 bytes, specifically 32 bytes of
      serial
      number plus 5 bytes of header.
      N.B. This means a 36-byte CbCS designation descriptor field is not
      large
      enough to hold it. (I just realized this myself, and have not yet
      decided how to fix it.)
      All the best,
      .Ralph
      *
      * For T10 Reflector information, send a message with
      * 'info t10' (no quotes) in the message body to majordomo at t10.org
      *
      * For T10 Reflector information, send a message with
      * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Wed Mar 19 12:23:56 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 19 Mar 2008 13:23:56 -0600
Subject: T10 minutes posted
Message-ID: <mailman.272.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft minutes of T10 meeting #84 are available at:
   http://www.t10.org/ftp/t10/document.08/08-133r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Elliott at hp.com  Wed Mar 19 15:28:32 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 19 Mar 2008 22:28:32 +0000
Subject: SES-2 revision 19c now available
Message-ID: <mailman.273.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
SCSI Enclosure Services - 2 (SES-2) revision 19c is now
available on http://www.t10.org/drafts.htm and
http://www.t10.org/new.htm, incorporating resolutions for
all comments.
ses2r19c.pdf is the new working draft incorporating the changes.
	     Change bars reflect changes since ses2r19.
07-512r0.pdf contains the original letter ballot comments.
08-049r2.pdf contains ses2r19 side-by-side with the comments
	     (including resolution status).
08-049r2.fdf contains just the comments (including resolution status)
	     and can be imported into ses2r19.pdf using full Acrobat.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Thu Mar 20 09:21:48 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 20 Mar 2008 10:21:48 -0600
Subject: T10 Reflector clean up
Message-ID: <mailman.274.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
#
#
#
#
#
#
#
#
#
#
It is time again to clean up the T10 Reflector. The following addresses have
bounced consistently since the last clean up:
Addresses removed:
  BMiller at AssembleTech.com
  wcgintz at ix.netcom.com
  peter at mellquist.org
  Andy.Alm at lsi.com
  rdeglin at vitesse.com
  bob.mulcahy at incipient.com
  Rodney.Dekoning at sun.com
  kiran-kumar.kasturi at hp.com
  fdelabre at capgemini.fr
  eric.lanning at finisar.com
  tommi_salli at symantec.com
  mdobie at us.ibm.com
  scsi_info at hamble.demon.co.uk
These people may re-subscribe (hopefully, with a better address) by sending
an email to majordomo at t10.org with the following line in the message body:
  subscribe t10
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Thu Mar 20 14:48:25 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 20 Mar 2008 14:48:25 -0700
Subject: SSC-3: Late Letter Ballot comment
Message-ID: <mailman.275.1441607336.22514.t10@sandbox.t10.org>

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

I received communication from an ISV today related to Encryption mode 
locking (4.2.21.11).  They were unable to determine if the locking applied 
when the data encryption parameters were set such that 
encryption/decryption is turned off.  In a close reading this clause 
refers to "...locked to that set of data encryption parameters and key 
instance counter value until a hard reset condition occurs or another 
[SPOUT command is received]"
In 4.2.21.6 Managing keys within the physical device, where it describes 
when to release a set of data encryption parameters, there is no mention 
of turning off encryption.  Therefore, the locking does apply to the saved 
set of encryption parameters even when encryption is turned off.  This is 
indeed the desired behavior.  However, it is not clear to the casual or 
novice standards reader that this is the case.
Proposed Solution (Editorial):
In 4.2.21.11, p2, add a new sentence after s1:
The LOCK bit in the Set Data Encryption page is set to one to lock the I_T 
nexus that issued the SECURITY PROTOCOL OUT command to the set of data 
encryption parameters established at the completion of the processing of 
the command.  A set of data encryption parameters are established and 
locked even if the ENCRYPTION MODE is set to DISABLE and the DECRYPTION 
MODE is set to DISABLE.
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


From lohmeyer at t10.org  Sat Mar 22 23:01:16 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 23 Mar 2008 00:01:16 -0600
Subject: Recent T10 documents uploaded since 2008/03/16
Message-ID: <mailman.276.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SES-2 revision 19 letter ballot comment resolution as of ses2r19c
(by: Rob Elliott)
T10/08-049r2   Uploaded: 2008/03/19   1561220 bytes
ftp://ftp.t10.org/t10/document.08/08-049r2.fdf
SES-2 revision 19 letter ballot comment resolution as of ses2r19c
(by: Rob Elliott)
T10/08-049r2   Uploaded: 2008/03/19   2868042 bytes
ftp://ftp.t10.org/t10/document.08/08-049r2.pdf
SPC-4, Completing the SET IDENTIFYING INFORMATION command
(by: Mark Evans)
T10/08-108r1   Uploaded: 2008/03/17   116462 bytes
ftp://ftp.t10.org/t10/document.08/08-108r1.pdf
Minutes of T10 Plenary Meeting #84 - March 13 2008
(by: Weber & Lohmeyer)
T10/08-133r0   Uploaded: 2008/03/19   135440 bytes
ftp://ftp.t10.org/t10/document.08/08-133r0.htm
Minutes of T10 Plenary Meeting #84 - March 13 2008
(by: Weber & Lohmeyer)
T10/08-133r0   Uploaded: 2008/03/19   334027 bytes
ftp://ftp.t10.org/t10/document.08/08-133r0.pdf
Comments on SAS2r14 Physical Layer
(by: Kevin Witt)
T10/08-144r1   Uploaded: 2008/03/21   911909 bytes
ftp://ftp.t10.org/t10/document.08/08-144r1.pdf
Proposed Changes to Receiver Device Physical Testing Section in SAS 2
Draft
(by: Michael Jenkins)
T10/08-146r1   Uploaded: 2008/03/18   118976 bytes
ftp://ftp.t10.org/t10/document.08/08-146r1.pdf
Agenda for T10 Meeting #85 May 2008
(by: John Lohmeyer)
T10/08-174r1   Uploaded: 2008/03/18   62045 bytes
ftp://ftp.t10.org/t10/document.08/08-174r1.pdf
T10 Project Summary -  March 2008
(by: John Lohmeyer)
T10/08-175r0   Uploaded: 2008/03/17   34468 bytes
ftp://ftp.t10.org/t10/document.08/08-175r0.pdf
Jeopardy Letter for May 2008 meeting
(by: John Lohmeyer)
T10/08-176r0   Uploaded: 2008/03/17   88702 bytes
ftp://ftp.t10.org/t10/document.08/08-176r0.pdf
Fixes for six OSD-2 bugs
(by: Ralph O. Weber)
T10/08-179r0   Uploaded: 2008/03/19   41937 bytes
ftp://ftp.t10.org/t10/document.08/08-179r0.pdf
SCSI device name cleanup in SPC-4
(by: Ralph O. Weber)
T10/08-180r0   Uploaded: 2008/03/19   30768 bytes
ftp://ftp.t10.org/t10/document.08/08-180r0.pdf
Set Attributes error handling in OSD-2
(by: Ralph O. Weber)
T10/08-181r0   Uploaded: 2008/03/19   34618 bytes
ftp://ftp.t10.org/t10/document.08/08-181r0.pdf
Working Drafts
--------------
SCSI Block Commands - 3 (SBC-3)
(Editor: Mark Evans)
 Rev: 14       Uploaded: 2008/03/20   1460175 bytes
ftp://ftp.t10.org/t10/drafts/sbc3/sbc3r14.pdf
SCSI Enclosure Services - 2 (SES-2)
(Editor: Rob Elliott)
 Rev: 19c      Uploaded: 2008/03/19   805676 bytes
ftp://ftp.t10.org/t10/drafts/ses2/ses2r19c.pdf
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 14       Uploaded: 2008/03/17   4329095 bytes
ftp://ftp.t10.org/t10/drafts/spc4/spc4r14.pdf
(Report generated on 2008/03/23 at 00:01:16)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Sun Mar 23 21:46:09 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 24 Mar 2008 13:46:09 +0900
Subject: Reflector cleanup notice
Message-ID: <mailman.277.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
The following people have bounced repeatedly and removed from mtfuji5
reflector:
 alexlin at intervideo.com.cn
They may get back on the reflector by sending a message to
majordomo at avc-pioneer.com with the following line in the message body:
subscribe mtfuji5
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From takeshi_kohda at post.pioneer.co.jp  Sun Mar 23 22:40:51 2008
From: takeshi_kohda at post.pioneer.co.jp (takeshi_kohda at post.pioneer.co.jp)
Date: Mon, 24 Mar 2008 14:40:51 +0900
Subject: clarification of READ DISC STRUCTURE command FFh
Message-ID: <mailman.278.1441607336.22514.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0803240_1">1</A>

Hello all,
I would like to propose to add one sentense in READ DISC STRUCTURE command
FFh
description for clarification purpose.
Please see the attached file.
Best regards,
---
Takeshi Kohda
(See attached file: RDS_FF$B#h(B.pdf)


From Gerry.Houlder at seagate.com  Mon Mar 24 10:49:44 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 24 Mar 2008 12:49:44 -0500
Subject: Fw: Comment on SAM-4 rev. 13c
Message-ID: <mailman.279.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I just noticed that SAM-3 has equivalent wording that says "64 bits" for
maximum size of task identifier. I am now suspicious that the change from
bits to bytes is probably not intended and should be changed back. Can you
consider this to be a late comment against SAM-4?
----- Forwarded by Gerry Houlder/Seagate on 03/24/2008 12:45 PM -----
	     Gerry							   
	     Houlder/Seagate						   
	     (952) 402-2869						To 
				       George Penokie			   
									cc 
	     03/24/2008 11:17						   
	     AM 						   Subject 
				       Comment on SAM-4 rev. 13c	   
Hi George,
I have notice this sentence from the first paragraph of clause 4.7.2. puts
a limit of 64 bytes on the command identifier. This seems overly large to
me, shouldn't the limit be more like 64 bits (i.e., 8 bytes)? Is this
perhaps a typo? Are there really any protocols that define this larger than
4 bytes anyway?
Each SCSI transport protocol defines the size of the command identifier, up
to a maximum of 64 bytes, to be used
by SCSI ports that support that SCSI transport protocol.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Mon Mar 24 12:02:01 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 24 Mar 2008 12:02:01 -0700
Subject: IKEv2-SCSI Timeout Values inconsistency in SPC-4
Message-ID: <mailman.280.1441607336.22514.t10@sandbox.t10.org>

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

In SPC-4r14
There seems to be an inconsistency between 5.13.4.8.3 and Table 387 o page 
450.
Table 387 has two rows indicating timeout values that are not talked about 
in 5.13.4.8.3.
first row under "SECURITY PROTOCOL IN command with SECURITY PROTOCOL 
SPECIFIC field set to 0102h (i.e., Key Exchange step) Authentication step 
not skipped"
and first row under "SECURITY PROTOCOL IN command with SECURITY PROTOCOL 
SPECIFIC field set to 0102h (i.e., Key Exchange step) Authentication step 
skipped" have 
"84h (i.e., IKEv2-SCSI Timeout Values)"
Since text takes precedence over tables it appears that these timeout 
values are not returned.  However, this does appear to be inconsistent 
with each other.
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


From George.Penokie at lsi.com  Mon Mar 24 12:00:41 2008
From: George.Penokie at lsi.com (Penokie, George)
Date: Mon, 24 Mar 2008 13:00:41 -0600
Subject: Comment on SAM-4 rev. 13c
Message-ID: <mailman.281.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Penokie, George" <George.Penokie at lsi.com>
*
Gerry,
You are correct, it should be 64 bits. I will put it in as a Seagate
letter ballot comment. 
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Monday, March 24, 2008 12:50 PM
To: t10 at t10.org
Subject: Fw: Comment on SAM-4 rev. 13c
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I just noticed that SAM-3 has equivalent wording that says "64 bits" for
maximum size of task identifier. I am now suspicious that the change
|from bits to bytes is probably not intended and should be changed back.
Can you consider this to be a late comment against SAM-4?
----- Forwarded by Gerry Houlder/Seagate on 03/24/2008 12:45 PM -----
	     Gerry
	     Houlder/Seagate
	     (952) 402-2869
To 
				       George Penokie
cc 
	     03/24/2008 11:17
	     AM
Subject 
				       Comment on SAM-4 rev. 13c
Hi George,
I have notice this sentence from the first paragraph of clause 4.7.2.
puts a limit of 64 bytes on the command identifier. This seems overly
large to me, shouldn't the limit be more like 64 bits (i.e., 8 bytes)?
Is this perhaps a typo? Are there really any protocols that define this
larger than
4 bytes anyway?
Each SCSI transport protocol defines the size of the command identifier,
up to a maximum of 64 bytes, to be used by SCSI ports that support that
SCSI transport protocol.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Mon Mar 24 11:59:57 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 24 Mar 2008 13:59:57 -0500
Subject: Things I don't like about proposal 08-126
Message-ID: <mailman.282.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed to
this for several reasons:
(a) Investigation of my company's SATA implementation (which includes both
STANDBY and SLEEP states) shows that SLEEP state has the same power savings
as STANDBY. Since SLEEP provides no power savings over STANDBY there is no
advantage for it. I recommend other companies look into what they might do
differently for SLEEP versus STANDBY so I can be sure my analysis is
typical of the industry.
(b) SLEEP is a lot more trouble for the initiator in terms of what it has
to do to wake up a target and initialize it to accept commands. If it
provides no power savings, the extra trouble is not worth it.
(c) Even if I thought SLEEP was useful, using a timer expiration to invoke
SLEEP is a bad thing. If a target goes into SLEEP mode without the
initiator's knowledge, the initiator will probably try to send it a command
and get unexpected timeout. The initiator will likely assume (by today's
interpretation) the target has died and will flag it as such. SATA gets
around this issue by only allowing SLEEP to be entered by express command
|from the initiator. In this way the initiator should know that the target
is put to SLEEP and should know that the WAKEUP procedure is needed before
sending a command. This suggests that even interfaces that define and use
SLEEP do not want this state to be entered by targets on their own accord
(e.g., timer expiration).
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Mon Mar 24 13:06:13 2008
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Mon, 24 Mar 2008 16:06:13 -0400
Subject: Things I don't like about proposal 08-126
Message-ID: <mailman.283.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
I absolutely agree with point (c).
Standby and Idle take no special action to enter (timer based), and they
take no special action to exit (just send a command).  Those power modes
(aside from their timing) can be pretty much transparent to the host.
Sleep however takes special action to exit, and therefore should take
special action to enter.  There is nothing transparent about sleep; the
host must know it needs to take special action to issue the WAKEUP,
therefore the host must know when the device is in that state.	Since
the host can not query to findout if the device is in sleep mode, the
only other option is to have the host be the one that puts the device
into that state.
Automatic (timer based) transition to sleep is bad.
	Fred Knight
	NetApp
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com] 
Sent: Monday, March 24, 2008 3:00 PM
To: t10 at t10.org
Subject: Things I don't like about proposal 08-126
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed
to this for several reasons:
(a) Investigation of my company's SATA implementation (which includes
both STANDBY and SLEEP states) shows that SLEEP state has the same power
savings as STANDBY. Since SLEEP provides no power savings over STANDBY
there is no advantage for it. I recommend other companies look into what
they might do differently for SLEEP versus STANDBY so I can be sure my
analysis is typical of the industry.
(b) SLEEP is a lot more trouble for the initiator in terms of what it
has to do to wake up a target and initialize it to accept commands. If
it provides no power savings, the extra trouble is not worth it.
(c) Even if I thought SLEEP was useful, using a timer expiration to
invoke SLEEP is a bad thing. If a target goes into SLEEP mode without
the initiator's knowledge, the initiator will probably try to send it a
command and get unexpected timeout. The initiator will likely assume (by
today's
interpretation) the target has died and will flag it as such. SATA gets
around this issue by only allowing SLEEP to be entered by express
command from the initiator. In this way the initiator should know that
the target is put to SLEEP and should know that the WAKEUP procedure is
needed before sending a command. This suggests that even interfaces that
define and use SLEEP do not want this state to be entered by targets on
their own accord (e.g., timer expiration).
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From James.C.Hatfield at seagate.com  Mon Mar 24 13:35:35 2008
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Mon, 24 Mar 2008 14:35:35 -0600
Subject: Things I don't like about proposal 08-126
Message-ID: <mailman.284.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
For dual ported devices: Another reason for not supporting SLEEP is that
one initiator could put it to sleep
without the knowledge of another.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
	     Gerry.Houlder at sea						   
	     gate.com							   
	     Sent by:							To 
	     owner-t10 at t10.org	       t10 at t10.org			   
	     (952) 402-2869						cc 
								   Subject 
	     03/24/2008 12:59	       Things I don't like about proposal  
	     PM 		       08-126				   
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed to
this for several reasons:
(a) Investigation of my company's SATA implementation (which includes both
STANDBY and SLEEP states) shows that SLEEP state has the same power savings
as STANDBY. Since SLEEP provides no power savings over STANDBY there is no
advantage for it. I recommend other companies look into what they might do
differently for SLEEP versus STANDBY so I can be sure my analysis is
typical of the industry.
(b) SLEEP is a lot more trouble for the initiator in terms of what it has
to do to wake up a target and initialize it to accept commands. If it
provides no power savings, the extra trouble is not worth it.
(c) Even if I thought SLEEP was useful, using a timer expiration to invoke
SLEEP is a bad thing. If a target goes into SLEEP mode without the
initiator's knowledge, the initiator will probably try to send it a command
and get unexpected timeout. The initiator will likely assume (by today's
interpretation) the target has died and will flag it as such. SATA gets
around this issue by only allowing SLEEP to be entered by express command
|from the initiator. In this way the initiator should know that the target
is put to SLEEP and should know that the WAKEUP procedure is needed before
sending a command. This suggests that even interfaces that define and use
SLEEP do not want this state to be entered by targets on their own accord
(e.g., timer expiration).
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Paul.Suhler at Quantum.Com  Mon Mar 24 14:48:10 2008
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Mon, 24 Mar 2008 14:48:10 -0700
Subject: IKEv2-SCSI Timeout Values inconsistency in SPC-4
Message-ID: <mailman.285.1441607336.22514.t10@sandbox.t10.org>

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

Moreover, Table 385 on page 447 shows a value of 83h for IKEv2-SCSI
Timeout Values, while Table 387 shows the value as 84h.
Thanks,
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.1450 | paul.suhler at quantum.com  
___________________________________
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individual(s) or organization(s), without restriction.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Monday, March 24, 2008 12:02 PM
To: t10 at t10.org
Subject: IKEv2-SCSI Timeout Values inconsistency in SPC-4
In SPC-4r14 
There seems to be an inconsistency between 5.13.4.8.3 and Table 387 o
page 450. 
Table 387 has two rows indicating timeout values that are not talked
about in 5.13.4.8.3. 
first row under "SECURITY PROTOCOL IN command with SECURITY PROTOCOL
SPECIFIC field set to 0102h (i.e., Key Exchange step) Authentication
step not skipped" 
and first row under "SECURITY PROTOCOL IN command with SECURITY PROTOCOL
SPECIFIC field set to 0102h (i.e., Key Exchange step) Authentication
step skipped" have 
"84h (i.e., IKEv2-SCSI Timeout Values)" 
Since text takes precedence over tables it appears that these timeout
values are not returned.  However, this does appear to be inconsistent
with each other. 
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/ 
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.


From MOverby at nvidia.com  Mon Mar 24 16:37:50 2008
From: MOverby at nvidia.com (Mark Overby)
Date: Mon, 24 Mar 2008 16:37:50 -0700
Subject: Things I don't like about proposal 08-126
Message-ID: <mailman.286.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Mark Overby <MOverby at nvidia.com>
*
However, in a real SCSI world you'd get an ASC(Q) to the other initiator (at
least that's the way I understood the proposal) indicating that an
initializing command is required.
On 3/24/08 1:35 PM, "James.C.Hatfield at seagate.com"
<James.C.Hatfield at seagate.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * James.C.Hatfield at seagate.com
> *
> For dual ported devices: Another reason for not supporting SLEEP is that
> one initiator could put it to sleep
> without the knowledge of another.
> 
> Thank You !!!
> -----------------------------------------------------------------
> Jim Hatfield
> Seagate Technology LLC
>    e-mail:  James.C.Hatfield at seagate.com
>    s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>    voice:  720-684-2120
>    fax....:  720-684-2711
> ==========================================
> 
> 
>		   
>	       Gerry.Houlder at sea
>	       gate.com
>	       Sent by: 						  To
>	       owner-t10 at t10.org	 t10 at t10.org
>	       (952) 402-2869						  cc
>		   
>								     Subject
>	       03/24/2008 12:59 	 Things I don't like about proposal
>	       PM			 08-126
>		   
>		   
>		   
>		   
>		   
>		   
> 
> 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> 
> Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed to
> this for several reasons:
> 
> (a) Investigation of my company's SATA implementation (which includes both
> STANDBY and SLEEP states) shows that SLEEP state has the same power savings
> as STANDBY. Since SLEEP provides no power savings over STANDBY there is no
> advantage for it. I recommend other companies look into what they might do
> differently for SLEEP versus STANDBY so I can be sure my analysis is
> typical of the industry.
> 
> (b) SLEEP is a lot more trouble for the initiator in terms of what it has
> to do to wake up a target and initialize it to accept commands. If it
> provides no power savings, the extra trouble is not worth it.
> 
> (c) Even if I thought SLEEP was useful, using a timer expiration to invoke
> SLEEP is a bad thing. If a target goes into SLEEP mode without the
> initiator's knowledge, the initiator will probably try to send it a command
> and get unexpected timeout. The initiator will likely assume (by today's
> interpretation) the target has died and will flag it as such. SATA gets
> around this issue by only allowing SLEEP to be entered by express command
> from the initiator. In this way the initiator should know that the target
> is put to SLEEP and should know that the WAKEUP procedure is needed before
> sending a command. This suggests that even interfaces that define and use
> SLEEP do not want this state to be entered by targets on their own accord
> (e.g., timer expiration).
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Mon Mar 24 19:38:51 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 25 Mar 2008 11:38:51 +0900
Subject: Things I don't like about proposal 08-126
Message-ID: <mailman.287.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello Gerry and Rob,
I have two opinions and two questions.
1. two opinions
I think that we may not need to have "sleep condition timer". If a system
wants
to go into power off, the system should take care any things might be lost.
I think that multi host problem may not an issue of the device side. The
multi
host system may have a system to communicate each other.
2. two questions
for Gerry,
To remove a device from system, what commands should host issue to the
device?
Currently it may be Sleep request of the Start/Stop unit command. (But OSs
use
Sync cache.)
for Rob,
Is the Sleep state an option for device?
If I do not want to implement Sleep in my device, I may not implement it. In
this case the request is terminated with Check Condition.
Best regards,
Keiji Katata
PIONEER CORP.
Gerry.Houlder at seagate.com@t10.org on 2008/03/25 03:59:57
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B:  t10 at t10.org
cc:
$B7oL>(B:  Things I don't like about proposal 08-126
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed to
this for several reasons:
(a) Investigation of my company's SATA implementation (which includes both
STANDBY and SLEEP states) shows that SLEEP state has the same power savings
as STANDBY. Since SLEEP provides no power savings over STANDBY there is no
advantage for it. I recommend other companies look into what they might do
differently for SLEEP versus STANDBY so I can be sure my analysis is
typical of the industry.
(b) SLEEP is a lot more trouble for the initiator in terms of what it has
to do to wake up a target and initialize it to accept commands. If it
provides no power savings, the extra trouble is not worth it.
(c) Even if I thought SLEEP was useful, using a timer expiration to invoke
SLEEP is a bad thing. If a target goes into SLEEP mode without the
initiator's knowledge, the initiator will probably try to send it a command
and get unexpected timeout. The initiator will likely assume (by today's
interpretation) the target has died and will flag it as such. SATA gets
around this issue by only allowing SLEEP to be entered by express command
|from the initiator. In this way the initiator should know that the target
is put to SLEEP and should know that the WAKEUP procedure is needed before
sending a command. This suggests that even interfaces that define and use
SLEEP do not want this state to be entered by targets on their own accord
(e.g., timer expiration).
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From MOverby at nvidia.com  Mon Mar 24 21:05:56 2008
From: MOverby at nvidia.com (Mark Overby)
Date: Mon, 24 Mar 2008 21:05:56 -0700
Subject: Things I don't like about proposal 08-126
Message-ID: <mailman.288.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Mark Overby <MOverby at nvidia.com>
*
I agree with Keiji-San on point #1. I do not think the sleep condition timer
is necessary and will introduce more problems than it purports to solve.
On 3/24/08 7:38 PM, "keiji_katata at post.pioneer.co.jp"
<keiji_katata at post.pioneer.co.jp> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * keiji_katata at post.pioneer.co.jp
> *
> 
> Hello Gerry and Rob,
> 
> I have two opinions and two questions.
> 
> 1. two opinions
> 
> I think that we may not need to have "sleep condition timer". If a system
> wants
> to go into power off, the system should take care any things might be lost.
> 
> I think that multi host problem may not an issue of the device side. The
multi
> host system may have a system to communicate each other.
> 
> 
> 2. two questions
> 
> for Gerry,
> To remove a device from system, what commands should host issue to the
device?
> Currently it may be Sleep request of the Start/Stop unit command. (But OSs
use
> Sync cache.)
> 
> for Rob,
> Is the Sleep state an option for device?
> If I do not want to implement Sleep in my device, I may not implement it.
In
> this case the request is terminated with Check Condition.
> 
> Best regards,
> 
> Keiji Katata
> PIONEER CORP.
> 
> 
> 
> 
> 
> Gerry.Houlder at seagate.com@t10.org on 2008/03/25 03:59:57
> 
> $BAw?.<T(B:     owner-t10 at t10.org
> 
> 
> 
> 
> 
> 
> 
> $B08 at h(B:  t10 at t10.org
> cc:
> $B7oL>(B:  Things I don't like about proposal 08-126
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> 
> Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed to
> this for several reasons:
> 
> (a) Investigation of my company's SATA implementation (which includes both
> STANDBY and SLEEP states) shows that SLEEP state has the same power savings
> as STANDBY. Since SLEEP provides no power savings over STANDBY there is no
> advantage for it. I recommend other companies look into what they might do
> differently for SLEEP versus STANDBY so I can be sure my analysis is
> typical of the industry.
> 
> (b) SLEEP is a lot more trouble for the initiator in terms of what it has
> to do to wake up a target and initialize it to accept commands. If it
> provides no power savings, the extra trouble is not worth it.
> 
> (c) Even if I thought SLEEP was useful, using a timer expiration to invoke
> SLEEP is a bad thing. If a target goes into SLEEP mode without the
> initiator's knowledge, the initiator will probably try to send it a command
> and get unexpected timeout. The initiator will likely assume (by today's
> interpretation) the target has died and will flag it as such. SATA gets
> around this issue by only allowing SLEEP to be entered by express command
> from the initiator. In this way the initiator should know that the target
> is put to SLEEP and should know that the WAKEUP procedure is needed before
> sending a command. This suggests that even interfaces that define and use
> SLEEP do not want this state to be entered by targets on their own accord
> (e.g., timer expiration).
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> 
> 
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From George.Penokie at lsi.com  Tue Mar 25 05:40:57 2008
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 25 Mar 2008 06:40:57 -0600
Subject: Things I don't like about proposal 08-126
Message-ID: <mailman.289.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Penokie, George" <George.Penokie at lsi.com>
*
Mark,
Well, not quite. To get a response to a command, any command, the device
has to come out of sleep which would delay the response to that command
and possibly cause a command timeout. Remember it's the device that is
in sleep mode not the port so all ports would have the delay. 
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark
Overby
Sent: Monday, March 24, 2008 6:38 PM
To: James.C.Hatfield at seagate.com; t10 at t10.org
Subject: Re: Things I don't like about proposal 08-126
* From the T10 Reflector (t10 at t10.org), posted by:
* Mark Overby <MOverby at nvidia.com>
*
However, in a real SCSI world you'd get an ASC(Q) to the other initiator
(at least that's the way I understood the proposal) indicating that an
initializing command is required.
On 3/24/08 1:35 PM, "James.C.Hatfield at seagate.com"
<James.C.Hatfield at seagate.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * James.C.Hatfield at seagate.com
> *
> For dual ported devices: Another reason for not supporting SLEEP is 
> that one initiator could put it to sleep without the knowledge of 
> another.
> 
> Thank You !!!
> -----------------------------------------------------------------
> Jim Hatfield
> Seagate Technology LLC
>    e-mail:  James.C.Hatfield at seagate.com
>    s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>    voice:  720-684-2120
>    fax....:  720-684-2711
> ==========================================
> 
> 
>		   
>	       Gerry.Houlder at sea
>	       gate.com
>	       Sent by:
To
>	       owner-t10 at t10.org	 t10 at t10.org
>	       (952) 402-2869
cc
>		   
>
Subject
>	       03/24/2008 12:59 	 Things I don't like about
proposal
>	       PM			 08-126
>		   
>		   
>		   
>		   
>		   
>		   
> 
> 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> 
> Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed
> to this for several reasons:
> 
> (a) Investigation of my company's SATA implementation (which includes 
> both STANDBY and SLEEP states) shows that SLEEP state has the same 
> power savings as STANDBY. Since SLEEP provides no power savings over 
> STANDBY there is no advantage for it. I recommend other companies look
> into what they might do differently for SLEEP versus STANDBY so I can 
> be sure my analysis is typical of the industry.
> 
> (b) SLEEP is a lot more trouble for the initiator in terms of what it 
> has to do to wake up a target and initialize it to accept commands. If
> it provides no power savings, the extra trouble is not worth it.
> 
> (c) Even if I thought SLEEP was useful, using a timer expiration to 
> invoke SLEEP is a bad thing. If a target goes into SLEEP mode without 
> the initiator's knowledge, the initiator will probably try to send it 
> a command and get unexpected timeout. The initiator will likely assume
> (by today's
> interpretation) the target has died and will flag it as such. SATA 
> gets around this issue by only allowing SLEEP to be entered by express
> command from the initiator. In this way the initiator should know that
> the target is put to SLEEP and should know that the WAKEUP procedure 
> is needed before sending a command. This suggests that even interfaces
> that define and use SLEEP do not want this state to be entered by 
> targets on their own accord (e.g., timer expiration).
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
------------------------------------------------------------------------
-----------
This email message is for the sole use of the intended recipient(s) and
may contain confidential information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.
------------------------------------------------------------------------
-----------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Tue Mar 25 08:59:19 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 25 Mar 2008 08:59:19 -0700
Subject: CbCS Conference Call - Potential times
Message-ID: <mailman.290.1441607336.22514.t10@sandbox.t10.org>

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

I plan to schedule a CbCS conference call.  Please respond with what time 
|from the following list is your preferred time to meet.
Sivan will not be available the week of April 28.  In order to give 2 
weeks notice that gives us the following options.
Wed  April 16  12:00 AM - 2:00 PM PDT
Thur April 17  9:00 AM - 11:00 AM PDT
Tues April 22 12:00 PM - 2:00 PM PDT
Wed  April 23 9:00 AM - 11:00 AM PDT
Thur April 24 9:00 AM - 11:00 AM PDT
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


From kdbutt at us.ibm.com  Tue Mar 25 13:40:13 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 25 Mar 2008 13:40:13 -0700
Subject: IKEv2-SCSI Timeout Values inconsistency in SPC-4
Message-ID: <mailman.291.1441607336.22514.t10@sandbox.t10.org>

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

Another error.
Table 387 page 451 has an error.  It shows:
23h (i.e., Identification ? Device Server)
But should be 24h since 23h is the Identification - Application Client
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/ 
"Paul Suhler" <Paul.Suhler at Quantum.Com> 
03/24/2008 02:48 PM
To
Kevin D Butt/Tucson/IBM at IBMUS, <t10 at t10.org>
cc
Subject
RE: IKEv2-SCSI Timeout Values inconsistency in SPC-4
Moreover, Table 385 on page 447 shows a value of 83h for IKEv2-SCSI 
Timeout Values, while Table 387 shows the value as 84h.
Thanks,
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 
949.856.1450 | paul.suhler at quantum.com
___________________________________
Disregard the Quantum Corporation confidentiality notice below.  The 
information contained in this transmission is not confidential. Permission 
is hereby explicitly granted to disclose, copy, and further distribute to 
any individual(s) or organization(s), without restriction.
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Monday, March 24, 2008 12:02 PM
To: t10 at t10.org
Subject: IKEv2-SCSI Timeout Values inconsistency in SPC-4
In SPC-4r14 
There seems to be an inconsistency between 5.13.4.8.3 and Table 387 o page 
450. 
Table 387 has two rows indicating timeout values that are not talked about 
in 5.13.4.8.3. 
first row under "SECURITY PROTOCOL IN command with SECURITY PROTOCOL 
SPECIFIC field set to 0102h (i.e., Key Exchange step) Authentication step 
not skipped" 
and first row under "SECURITY PROTOCOL IN command with SECURITY PROTOCOL 
SPECIFIC field set to 0102h (i.e., Key Exchange step) Authentication step 
skipped" have 
"84h (i.e., IKEv2-SCSI Timeout Values)" 
Since text takes precedence over tables it appears that these timeout 
values are not returned.  However, this does appear to be inconsistent 
with each other. 
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/ 
The information contained in this transmission may be confidential. Any 
disclosure, copying, or further distribution of confidential information 
is not permitted unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not responsible 
for the proper and complete transmission of the substance of this 
communication or for any delay in its receipt.


From Kevin_Marks at Dell.com  Tue Mar 25 19:32:03 2008
From: Kevin_Marks at Dell.com (Kevin_Marks at Dell.com)
Date: Tue, 25 Mar 2008 21:32:03 -0500
Subject: Things I don't like about proposal 08-126
Message-ID: <mailman.292.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <Kevin_Marks at Dell.com>
*
It was my understanding that in Rob's proposal, the port is also
inactive, only looking for a hard reset event to trigger recovery.
Kevin
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Tuesday, March 25, 2008 7:41 AM
To: Mark Overby; James.C.Hatfield at seagate.com; t10 at t10.org
Subject: RE: Things I don't like about proposal 08-126
* From the T10 Reflector (t10 at t10.org), posted by:
* "Penokie, George" <George.Penokie at lsi.com>
*
Mark,
Well, not quite. To get a response to a command, any command, the device
has to come out of sleep which would delay the response to that command
and possibly cause a command timeout. Remember it's the device that is
in sleep mode not the port so all ports would have the delay. 
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark
Overby
Sent: Monday, March 24, 2008 6:38 PM
To: James.C.Hatfield at seagate.com; t10 at t10.org
Subject: Re: Things I don't like about proposal 08-126
* From the T10 Reflector (t10 at t10.org), posted by:
* Mark Overby <MOverby at nvidia.com>
*
However, in a real SCSI world you'd get an ASC(Q) to the other initiator
(at least that's the way I understood the proposal) indicating that an
initializing command is required.
On 3/24/08 1:35 PM, "James.C.Hatfield at seagate.com"
<James.C.Hatfield at seagate.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * James.C.Hatfield at seagate.com
> *
> For dual ported devices: Another reason for not supporting SLEEP is 
> that one initiator could put it to sleep without the knowledge of 
> another.
> 
> Thank You !!!
> -----------------------------------------------------------------
> Jim Hatfield
> Seagate Technology LLC
>    e-mail:  James.C.Hatfield at seagate.com
>    s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>    voice:  720-684-2120
>    fax....:  720-684-2711
> ==========================================
> 
> 
>		   
>	       Gerry.Houlder at sea
>	       gate.com
>	       Sent by:
To
>	       owner-t10 at t10.org	 t10 at t10.org
>	       (952) 402-2869
cc
>		   
>
Subject
>	       03/24/2008 12:59 	 Things I don't like about
proposal
>	       PM			 08-126
>		   
>		   
>		   
>		   
>		   
>		   
> 
> 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> 
> Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed
> to this for several reasons:
> 
> (a) Investigation of my company's SATA implementation (which includes 
> both STANDBY and SLEEP states) shows that SLEEP state has the same 
> power savings as STANDBY. Since SLEEP provides no power savings over 
> STANDBY there is no advantage for it. I recommend other companies look
> into what they might do differently for SLEEP versus STANDBY so I can 
> be sure my analysis is typical of the industry.
> 
> (b) SLEEP is a lot more trouble for the initiator in terms of what it 
> has to do to wake up a target and initialize it to accept commands. If
> it provides no power savings, the extra trouble is not worth it.
> 
> (c) Even if I thought SLEEP was useful, using a timer expiration to 
> invoke SLEEP is a bad thing. If a target goes into SLEEP mode without 
> the initiator's knowledge, the initiator will probably try to send it 
> a command and get unexpected timeout. The initiator will likely assume
> (by today's
> interpretation) the target has died and will flag it as such. SATA 
> gets around this issue by only allowing SLEEP to be entered by express
> command from the initiator. In this way the initiator should know that
> the target is put to SLEEP and should know that the WAKEUP procedure 
> is needed before sending a command. This suggests that even interfaces
> that define and use SLEEP do not want this state to be entered by 
> targets on their own accord (e.g., timer expiration).
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
------------------------------------------------------------------------
-----------
This email message is for the sole use of the intended recipient(s) and
may contain confidential information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.
------------------------------------------------------------------------
-----------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From MOverby at nvidia.com  Tue Mar 25 21:00:31 2008
From: MOverby at nvidia.com (Mark Overby)
Date: Tue, 25 Mar 2008 21:00:31 -0700
Subject: Things I don't like about proposal 08-126
Message-ID: <mailman.293.1441607336.22514.t10@sandbox.t10.org>

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

It appears I misunderstood.
On 3/25/08 7:32 PM, "Kevin_Marks at Dell.com" <Kevin_Marks at Dell.com> wrote:
> It was my understanding that in Rob's proposal, the port is also
> inactive, only looking for a hard reset event to trigger recovery.
> 
> Kevin
> 
> 
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
> George
> Sent: Tuesday, March 25, 2008 7:41 AM
> To: Mark Overby; James.C.Hatfield at seagate.com; t10 at t10.org
> Subject: RE: Things I don't like about proposal 08-126
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Penokie, George" <George.Penokie at lsi.com>
> *
> Mark,
> 
> Well, not quite. To get a response to a command, any command, the device
> has to come out of sleep which would delay the response to that command
> and possibly cause a command timeout. Remember it's the device that is
> in sleep mode not the port so all ports would have the delay.
> 
> 
> Bye for now,
> George Penokie
> 
> LSI Corporation
> 3033 41st St. NW
> Suite 100
> Rochester, MN 55901
> 
> 507-328-9017
> george.penokie at lsi.com
> 
> 
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark
> Overby
> Sent: Monday, March 24, 2008 6:38 PM
> To: James.C.Hatfield at seagate.com; t10 at t10.org
> Subject: Re: Things I don't like about proposal 08-126
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Mark Overby <MOverby at nvidia.com>
> *
> However, in a real SCSI world you'd get an ASC(Q) to the other initiator
> (at least that's the way I understood the proposal) indicating that an
> initializing command is required.
> 
> 
> On 3/24/08 1:35 PM, "James.C.Hatfield at seagate.com"
> <James.C.Hatfield at seagate.com> wrote:
> 
>> > * From the T10 Reflector (t10 at t10.org), posted by:
>> > * James.C.Hatfield at seagate.com
>> > *
>> > For dual ported devices: Another reason for not supporting SLEEP is
>> > that one initiator could put it to sleep without the knowledge of
>> > another.
>> >
>> > Thank You !!!
>> > -----------------------------------------------------------------
>> > Jim Hatfield
>> > Seagate Technology LLC
>> >	e-mail:  James.C.Hatfield at seagate.com
>> >	s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>> >	voice:	720-684-2120
>> >	fax....:  720-684-2711
>> > ==========================================
>> >
>> >
>> >		   
>> >		  Gerry.Houlder at sea
>> >		  gate.com
>> >		  Sent by:
> To
>> >		  owner-t10 at t10.org	    t10 at t10.org
>> >		  (952) 402-2869
> cc
>> >		   
>> >
> Subject
>> >		  03/24/2008 12:59	    Things I don't like about
> proposal
>> >		  PM			    08-126
>> >		   
>> >		   
>> >		   
>> >		   
>> >		   
>> >		   
>> >
>> >
>> >
>> >
>> > * From the T10 Reflector (t10 at t10.org), posted by:
>> > * Gerry.Houlder at seagate.com
>> > *
>> >
>> > Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed
> 
>> > to this for several reasons:
>> >
>> > (a) Investigation of my company's SATA implementation (which includes
>> > both STANDBY and SLEEP states) shows that SLEEP state has the same
>> > power savings as STANDBY. Since SLEEP provides no power savings over
>> > STANDBY there is no advantage for it. I recommend other companies look
> 
>> > into what they might do differently for SLEEP versus STANDBY so I can
>> > be sure my analysis is typical of the industry.
>> >
>> > (b) SLEEP is a lot more trouble for the initiator in terms of what it
>> > has to do to wake up a target and initialize it to accept commands. If
> 
>> > it provides no power savings, the extra trouble is not worth it.
>> >
>> > (c) Even if I thought SLEEP was useful, using a timer expiration to
>> > invoke SLEEP is a bad thing. If a target goes into SLEEP mode without
>> > the initiator's knowledge, the initiator will probably try to send it
>> > a command and get unexpected timeout. The initiator will likely assume
> 
>> > (by today's
>> > interpretation) the target has died and will flag it as such. SATA
>> > gets around this issue by only allowing SLEEP to be entered by express
> 
>> > command from the initiator. In this way the initiator should know that
> 
>> > the target is put to SLEEP and should know that the WAKEUP procedure
>> > is needed before sending a command. This suggests that even interfaces
> 
>> > that define and use SLEEP do not want this state to be entered by
>> > targets on their own accord (e.g., timer expiration).
>> >
>> > *
>> > * For T10 Reflector information, send a message with
>> > * 'info t10' (no quotes) in the message body to majordomo at t10.org
>> >
>> >
>> > *
>> > * For T10 Reflector information, send a message with
>> > * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> 
> ------------------------------------------------------------------------
> -----------
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all
> copies of the original message.
> ------------------------------------------------------------------------
> -----------
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 


From keiji_katata at post.pioneer.co.jp  Tue Mar 25 21:36:08 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Wed, 26 Mar 2008 13:36:08 +0900
Subject: FW: Mt. Fuji April meeting Information
Message-ID: <mailman.294.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
Here is the April meeting annoucement from TSST Korea.
I posted the attached file on ftp.
 ftp.avc-pioneer.com/Mtfuji_7/Proposal/Apr08/hotel rate.doc
Best regards,
Keiji Katata
PIONEER CORP.
---------------------- From: Keiji Katata/Pioneer Date: 2008/03/26 13:23
---------------------------
From:		takao.shirai
to:		owner-mtfuji5
Subject:	Mt. Fuji April meeting Information
Dear all,
We TSST hosts April Mt. Fuji meeting and meeting location is follow;
I$B!G(Bm very sorry too late information.
1. Meeting Date : April 15 ~16
2. Time :  10:00am ~ 6:00 pm
3. Location: The Shilla Hotel at Seoul.
4. Room : 23th ETOILES
5. Please refer to the below for Traffic information from Incheon
International
airport & Gimpo airport
    http://www.shilla.net/seoul/en/about/location01.jsp
    http://www.shilla.net/seoul/jp/about/location01.jsp
6. Hotel Reservation.
   If you want to make hotel reservation directly, please call the hotel at
+82-2-2233-3131 or book online
   (http://www.shilla.net/seoul/en/reservation/reservation_tmp_m.jsp).
	    * room rate of single(Deluxe room) : KRW 370,000
   Otherwise, you can contact to me (miky.oh at samsung.com) for hotel
reservation.
		   The deadline for hotel reservations is April 4, 2008
	    * room rate of single(Deluxe room) :  KRW 235,000 (This is a
special
rate for Mt. Fuji meeting.)
	      Attached is the Guest room service provided by the hotel.
 <<hotel rate.doc>>
If you need more information, please let me.
Best regards.
P.S. I will leave this activity at end of match. Thank your kindness.
--->-->->
Toshiba Samsung Storage Technology Corporation
Takao Shirai (takao.shirai at tsst.co.jp)
Solid Square,580,Horikawa-cho Saiwai-ku Kawasaki-shi Kanagawa 212-0013,Japan
Tel +81(44)543-3159 (Direct), Fax +81(44)541-2439
<-<--<---
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From dpeterso at Brocade.COM  Wed Mar 26 11:47:47 2008
From: dpeterso at Brocade.COM (David Peterson)
Date: Wed, 26 Mar 2008 12:47:47 -0600
Subject: [T11.3] FCP-4: Conference Call on April 2nd
Message-ID: <mailman.295.1441607336.22514.t10@sandbox.t10.org>

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

There will be a conference call to further discuss FC-4 Features object
and device type support (T10/08-127r0) and if time permits Defects in
FCP-4r00a (T10/08-137r0).
Call in details:
Wed Apr 2 11:00a-1:00p CDT 
Conference Code: 6128023299
Security passcode: 4491
Reservationless-Plus Toll Free Dial-In Number (US & Canada): (888)
878-2699
Reservationless-Plus International Dial-In Number:(706) 643-7329
Thanks...Dave


From dpeterso at brocade.com  Wed Mar 26 11:47:47 2008
From: dpeterso at brocade.com (David Peterson)
Date: Wed, 26 Mar 2008 12:47:47 -0600
Subject: FCP-4: Conference Call on April 2nd
Message-ID: <mailman.296.1441607336.22514.t10@sandbox.t10.org>

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

There will be a conference call to further discuss FC-4 Features object
and device type support (T10/08-127r0) and if time permits Defects in
FCP-4r00a (T10/08-137r0).
Call in details:
Wed Apr 2 11:00a-1:00p CDT 
Conference Code: 6128023299
Security passcode: 4491
Reservationless-Plus Toll Free Dial-In Number (US & Canada): (888)
878-2699
Reservationless-Plus International Dial-In Number:(706) 643-7329
Thanks...Dave


From Alvin.Cox at seagate.com  Wed Mar 26 13:11:53 2008
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 26 Mar 2008 15:11:53 -0500
Subject: SAS PHY conference call on 4/3 cancelled
Message-ID: <mailman.297.1441607336.22514.t10@sandbox.t10.org>

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

I will not be available for a PHY conference call next week due to travel. 
Below is the updated conference call schedule (also updated to CDT).
Conference calls:
4/10, 4/24, and 5/1
Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Daylight Time 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Alvin Cox
Seagate Technology, LLC
Office 405-381-8067
Cell 405-206-4809


From James.C.Hatfield at seagate.com  Wed Mar 26 13:50:36 2008
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Wed, 26 Mar 2008 14:50:36 -0600
Subject: ATAPI: check condition with SenseKey=0
Message-ID: <mailman.298.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
For an ATAPI device, can the device report CHECK CONDITION (CHK bit in
Status field)
and specify SenseKey=0 in the Error field ?
A cursory scan of SCSI-2 and SPC-4 shows several instances of non-zero
ASC/ASCQ codes
associated with SenseKey=0.
The question is:
      For ATAPI, can a Check condition only be reported if SenseKey is
non-zero ?
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From billmc37 at ctesc.net  Wed Mar 26 14:32:12 2008
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Wed, 26 Mar 2008 16:32:12 -0500
Subject: ATAPI: check condition with SenseKey=0
Message-ID: <mailman.299.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi Jim,
It is not forbidden. However,....
In the case of MMC (the only ATAPI thing in T10), we always describe 
situations where a command is terminated with CHECK CONDITION status and 
sense bytes SK/ASC/ASCQ are set to ... And we always specify a sense key 
that is not zero. We also describe situations (e.g. progress indication) 
where the Sense gets set with a TUR. If the staus is GOOD, then you know 
that REQUEST SENSE will return progress indication where sense key = 0.
Long ago and far away, when the drive actually performed background 
audio play for CD, we also had wimpy status of the play. But that was 
also associated with the GOOD status after TUR and a sense key of 0.
Cheers,
Bill McFerrin
James.C.Hatfield at seagate.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * James.C.Hatfield at seagate.com
> *
>
> For an ATAPI device, can the device report CHECK CONDITION (CHK bit in
> Status field)
> and specify SenseKey=0 in the Error field ?
>
> A cursory scan of SCSI-2 and SPC-4 shows several instances of non-zero
> ASC/ASCQ codes
> associated with SenseKey=0.
>
> The question is:
>	For ATAPI, can a Check condition only be reported if SenseKey is
> non-zero ?
>
> Thank You !!!
> -----------------------------------------------------------------
> Jim Hatfield
> Seagate Technology LLC
>    e-mail:  James.C.Hatfield at seagate.com
>    s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>    voice:  720-684-2120
>    fax....:  720-684-2711
> ==========================================
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>   
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From James.C.Hatfield at seagate.com  Wed Mar 26 14:39:16 2008
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Wed, 26 Mar 2008 15:39:16 -0600
Subject: ATAPI: check condition with SenseKey=0
Message-ID: <mailman.300.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
Bill,
Thank you for your info about MMC.
By the way, though, MMC is not the only ATAPI use in T10.
There are still ATAPI tape drives and (I hear rumor of) some ATAPI HDDs.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
	     Bill McFerrin						   
	     <billmc37 at ctesc.n						   
	     et>							To 
	     No Phone Info	       James.C.Hatfield at seagate.com	   
	     Available							cc 
				       T13 <T-13 at t13.org>, t10 at t10.org	   
								   Subject 
	     03/26/2008 03:32	       Re: ATAPI: check condition with	   
	     PM 		       SenseKey=0			   
Hi Jim,
It is not forbidden. However,....
In the case of MMC (the only ATAPI thing in T10), we always describe
situations where a command is terminated with CHECK CONDITION status and
sense bytes SK/ASC/ASCQ are set to ... And we always specify a sense key
that is not zero. We also describe situations (e.g. progress indication)
where the Sense gets set with a TUR. If the staus is GOOD, then you know
that REQUEST SENSE will return progress indication where sense key = 0.
Long ago and far away, when the drive actually performed background
audio play for CD, we also had wimpy status of the play. But that was
also associated with the GOOD status after TUR and a sense key of 0.
Cheers,
Bill McFerrin
James.C.Hatfield at seagate.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * James.C.Hatfield at seagate.com
> *
>
> For an ATAPI device, can the device report CHECK CONDITION (CHK bit in
> Status field)
> and specify SenseKey=0 in the Error field ?
>
> A cursory scan of SCSI-2 and SPC-4 shows several instances of non-zero
> ASC/ASCQ codes
> associated with SenseKey=0.
>
> The question is:
>	For ATAPI, can a Check condition only be reported if SenseKey is
> non-zero ?
>
> Thank You !!!
> -----------------------------------------------------------------
> Jim Hatfield
> Seagate Technology LLC
>    e-mail:  James.C.Hatfield at seagate.com
>    s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>    voice:  720-684-2120
>    fax....:  720-684-2711
> ==========================================
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From James.C.Hatfield at seagate.com  Wed Mar 26 20:37:05 2008
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Wed, 26 Mar 2008 20:37:05 -0700
Subject: [T13] Re: ATAPI: check condition with SenseKey=0
Message-ID: <mailman.301.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
Bill,
Thank you for your info about MMC.
By the way, though, MMC is not the only ATAPI use in T10.
There are still ATAPI tape drives and (I hear rumor of) some ATAPI HDDs.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
	     Bill McFerrin						   
	     <billmc37 at ctesc.n						   
	     et>							To 
	     No Phone Info	       James.C.Hatfield at seagate.com	   
	     Available							cc 
				       T13 <T-13 at t13.org>, t10 at t10.org	   
								   Subject 
	     03/26/2008 03:32	       Re: ATAPI: check condition with	   
	     PM 		       SenseKey=0			   
Hi Jim,
It is not forbidden. However,....
In the case of MMC (the only ATAPI thing in T10), we always describe
situations where a command is terminated with CHECK CONDITION status and
sense bytes SK/ASC/ASCQ are set to ... And we always specify a sense key
that is not zero. We also describe situations (e.g. progress indication)
where the Sense gets set with a TUR. If the staus is GOOD, then you know
that REQUEST SENSE will return progress indication where sense key = 0.
Long ago and far away, when the drive actually performed background
audio play for CD, we also had wimpy status of the play. But that was
also associated with the GOOD status after TUR and a sense key of 0.
Cheers,
Bill McFerrin
James.C.Hatfield at seagate.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * James.C.Hatfield at seagate.com
> *
>
> For an ATAPI device, can the device report CHECK CONDITION (CHK bit in
> Status field)
> and specify SenseKey=0 in the Error field ?
>
> A cursory scan of SCSI-2 and SPC-4 shows several instances of non-zero
> ASC/ASCQ codes
> associated with SenseKey=0.
>
> The question is:
>	For ATAPI, can a Check condition only be reported if SenseKey is
> non-zero ?
>
> Thank You !!!
> -----------------------------------------------------------------
> Jim Hatfield
> Seagate Technology LLC
>    e-mail:  James.C.Hatfield at seagate.com
>    s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>    voice:  720-684-2120
>    fax....:  720-684-2711
> ==========================================
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From James.C.Hatfield at seagate.com  Wed Mar 26 20:38:25 2008
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Wed, 26 Mar 2008 20:38:25 -0700
Subject: [T13] Re: ATAPI: check condition with SenseKey=0
Message-ID: <mailman.302.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
Bill,
Thank you for your info about MMC.
By the way, though, MMC is not the only ATAPI use in T10.
There are still ATAPI tape drives and (I hear rumor of) some ATAPI HDDs.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
	     Bill McFerrin						   
	     <billmc37 at ctesc.n						   
	     et>							To 
	     No Phone Info	       James.C.Hatfield at seagate.com	   
	     Available							cc 
				       T13 <T-13 at t13.org>, t10 at t10.org	   
								   Subject 
	     03/26/2008 03:32	       Re: ATAPI: check condition with	   
	     PM 		       SenseKey=0			   
Hi Jim,
It is not forbidden. However,....
In the case of MMC (the only ATAPI thing in T10), we always describe
situations where a command is terminated with CHECK CONDITION status and
sense bytes SK/ASC/ASCQ are set to ... And we always specify a sense key
that is not zero. We also describe situations (e.g. progress indication)
where the Sense gets set with a TUR. If the staus is GOOD, then you know
that REQUEST SENSE will return progress indication where sense key = 0.
Long ago and far away, when the drive actually performed background
audio play for CD, we also had wimpy status of the play. But that was
also associated with the GOOD status after TUR and a sense key of 0.
Cheers,
Bill McFerrin
James.C.Hatfield at seagate.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * James.C.Hatfield at seagate.com
> *
>
> For an ATAPI device, can the device report CHECK CONDITION (CHK bit in
> Status field)
> and specify SenseKey=0 in the Error field ?
>
> A cursory scan of SCSI-2 and SPC-4 shows several instances of non-zero
> ASC/ASCQ codes
> associated with SenseKey=0.
>
> The question is:
>	For ATAPI, can a Check condition only be reported if SenseKey is
> non-zero ?
>
> Thank You !!!
> -----------------------------------------------------------------
> Jim Hatfield
> Seagate Technology LLC
>    e-mail:  James.C.Hatfield at seagate.com
>    s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>    voice:  720-684-2120
>    fax....:  720-684-2711
> ==========================================
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From James.C.Hatfield at seagate.com  Wed Mar 26 20:36:32 2008
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Wed, 26 Mar 2008 20:36:32 -0700
Subject: [T13] ATAPI: check condition with SenseKey=0
Message-ID: <mailman.303.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
For an ATAPI device, can the device report CHECK CONDITION (CHK bit in
Status field)
and specify SenseKey=0 in the Error field ?
A cursory scan of SCSI-2 and SPC-4 shows several instances of non-zero
ASC/ASCQ codes
associated with SenseKey=0.
The question is:
      For ATAPI, can a Check condition only be reported if SenseKey is
non-zero ?
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From James.C.Hatfield at seagate.com  Wed Mar 26 22:38:34 2008
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Wed, 26 Mar 2008 23:38:34 -0600
Subject: [T13] Re: [T13] ATAPI: check condition with SenseKey=0
Message-ID: <mailman.304.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
(I should have prefaced my original question by saying that this is an
attempt
to resolve a letter ballot comment in ATA8-ACS, and not just trying to stir
the pot.)
This would not necessarily be a broken device.
Now, I don't claim to be an expert on differences between autosense and
explicitly
executing a REQUEST SENSE command, but I see several
specific instances in SPC-4 (r10) for which NO SENSE describes real errors
or warnings.
Perhaps I'm barking up the wrong tree, but it appears to my untrained eye
that for an ATAPI
device, it is conceivable that the device could report CHECK CONDITION and
reporting key=NO SENSE and having a non-zero sense code.
1) (table 27)
   NO SENSE: Indicates that there is no specific sense key information to
   be reported. This may occur
   for a successful command or for a command that receives CHECK CONDITION
   status because one
   of the FILEMARK, EOM, or ILI bits is set to one.
2) REQUEST SENSE command
   If the logical unit is in the idle power condition (see 5.9), the device
   server shall process a REQUEST SENSE
   command by:
   1) Returning parameter data containing sense data with the sense key set
   to NO SENSE and the additional
   sense code set to one of the following:
   A) LOW POWER CONDITION ON if the reason for entry into the idle power
   condition is unknown;
   B) IDLE CONDITION ACTIVATED BY TIMER if the logical unit entered the
   idle power condition due to the
   idle condition timer (see 7.4.12); and
   C) IDLE CONDITION ACTIVATED BY COMMAND if the logical unit entered the
   idle power condition due
   to receipt of a command requiring the idle power condition while it was
   in the standby power condition;
   and
   2) Complete the REQUEST SENSE command with GOOD status.
3) Table 308 - Method of reporting informational exceptions (MRIE) field
(part 2 of 2)
   Generate no sense: The device server shall report informational
   exception conditions by returning a
   CHECK CONDITION status. If the TEST bit is set to zero, the status may
   be returned after the informational
   exception condition occurs on any command for which GOOD status would
   have been
   returned. If the TEST bit is set to one, the status shall be returned on
   the next command received on
   any I_T nexus that is normally capable of returning an informational
   exception condition when the
   TEST bit is set to zero. The sense key shall be set to NO SENSE and the
   additional sense code shall
   indicate the cause of the informational exception condition.
   The command that returns the CHECK CONDITION for the informational
   exception
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
	     hlandis at indra.com						   
	     Sent by:							   
	     T-13-Owner at t13.or						To 
	     g								   
	     No Phone Info						cc 
	     Available							   
								   Subject 
				       [T13] Re: [T13] ATAPI: check	   
	     03/26/2008 10:24	       condition with SenseKey=0	   
	     PM 							   
	     Please respond to						   
	     hlandis at indra.com						   
I would call it a very broken device - the device claims to have an
check (error) condition but then changes its mind and has no check
(error) condition???
However, what if a device had multiple hosts, excuse me, multiple
initiators, and the error was cleared by the second initiator before the
request sense data could be read by the first initiator?  Is that
possible? Oh yea, this is T13, not T10.  :)
Hale
James.C.Hatfield at seagate.com wrote:
> For an ATAPI device, can the device report CHECK CONDITION (CHK bit in
> Status field)
> and specify SenseKey=0 in the Error field ?
>
> A cursory scan of SCSI-2 and SPC-4 shows several instances of non-zero
> ASC/ASCQ codes
> associated with SenseKey=0.
>
> The question is:
>	For ATAPI, can a Check condition only be reported if SenseKey is
> non-zero ?
--
++ Hale Landis ++ hlandis at indra.com ++
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at ieee.org  Thu Mar 27 04:58:06 2008
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 27 Mar 2008 06:58:06 -0500
Subject: IKEv2-SCSI Timeout Values inconsistency in SPC-4
Message-ID: <mailman.305.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
All of the issues cited in the e-mail messages reproduced below
have been noted for correction in the next SPC-4 revision.
The two rows indicating that the IKEv2-SCSI Timeout Values payload
is allowed in the Key Exchange In step have been marked for removal.
No other part of the IKEv2-SCSI definition allows use of the timeouts
payload during the Key Exchange In step.
All the best,
.Ralph
Kevin D Butt wrote:
>
> Another error.
>
> Table 387 page 451 has an error. It shows:
> 23h (i.e., Identification ? Device Server)
> But should be 24h since 23h is the Identification - Application Client
>
> 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/
>
>
> *"Paul Suhler" <Paul.Suhler at Quantum.Com>*
>
> 03/24/2008 02:48 PM
>
>	
> To
>	Kevin D Butt/Tucson/IBM at IBMUS, <t10 at t10.org>
> cc
>	
> Subject
>	RE: IKEv2-SCSI Timeout Values inconsistency in SPC-4
>
>
>
>	
>
>
>
>
>
> Moreover, Table 385 on page 447 shows a value of 83h for IKEv2-SCSI 
> Timeout Values, while Table 387 shows the value as 84h.
>
> Thanks,
>
> Paul
> *___________________________________**
> Paul A. Suhler* | Firmware Engineer |* **Quantum Corporation* | 
> *Office**:* 949.856.1450 | _paul.suhler at quantum.com_ 
> 
> *___________________________________*
> Disregard the Quantum Corporation confidentiality notice below. The 
> information contained in this transmission is not confidential. 
> Permission is hereby explicitly granted to disclose, copy, and further 
> distribute to any individual(s) or organization(s), without restriction.
>
>
> ------------------------------------------------------------------------
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of 
> *Kevin D Butt*
> Sent:* Monday, March 24, 2008 12:02 PM*
> To:* t10 at t10.org*
> Subject:* IKEv2-SCSI Timeout Values inconsistency in SPC-4
>
>
> In SPC-4r14
>
> There seems to be an inconsistency between 5.13.4.8.3 and Table 387 o 
> page 450.
>
> Table 387 has two rows indicating timeout values that are not talked 
> about in 5.13.4.8.3.
>
> first row under "SECURITY PROTOCOL IN command with SECURITY PROTOCOL 
> SPECIFIC field set to 0102h (i.e., Key Exchange step) Authentication 
> step not skipped"
>
> and first row under "SECURITY PROTOCOL IN command with SECURITY 
> PROTOCOL SPECIFIC field set to 0102h (i.e., Key Exchange step) 
> Authentication step skipped" have
>
> "84h (i.e., IKEv2-SCSI Timeout Values)"
>
> Since text takes precedence over tables it appears that these timeout 
> values are not returned. However, this does appear to be inconsistent 
> with each other.
>
> 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/
> ------------------------------------------------------------------------
> *The information contained in this transmission may be confidential. 
> Any disclosure, copying, or further distribution of confidential 
> information is not permitted unless such privilege is explicitly 
> granted in writing by Quantum Corporation. Furthermore, Quantum 
> Corporation is not responsible for the proper and complete 
> transmission of the substance of this communication or for any delay 
> in its receipt.*
> ------------------------------------------------------------------------
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Thu Mar 27 11:04:57 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 27 Mar 2008 11:04:57 -0700
Subject: CbCS Conference Call (April 22, 09:00 - 11:00 PDT)
Message-ID: <mailman.306.1441607336.22514.t10@sandbox.t10.org>

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

There will be a conference call to discuss CbCS on Tues April 22 from 9:00 
AM PDT to 11:00 AM PDT.
Hosted by IBM
Tues April 22 9:00 AM - 11:00 AM PDT 
Call-in Information
(877) 421-007
(770) 615-1378
Conf ID 986327
There is no webex planned.
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


From kdbutt at us.ibm.com  Thu Mar 27 12:36:17 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 27 Mar 2008 12:36:17 -0700
Subject: CbCS Conference Call (April 22, 09:00 - 11:00 PDT) - Call-in # correction
Message-ID: <mailman.307.1441607336.22514.t10@sandbox.t10.org>

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

Correction to call-in number.  It was missing a digit.
(877) 421-0017 
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/ 
Kevin D Butt/Tucson/IBM at IBMUS 
Sent by: owner-t10 at t10.org
03/27/2008 11:04 AM
To
t10 at t10.org
cc
Subject
CbCS Conference Call (April 22, 09:00 - 11:00 PDT)
There will be a conference call to discuss CbCS on Tues April 22 from 9:00 
AM PDT to 11:00 AM PDT. 
Hosted by IBM 
Tues April 22 9:00 AM - 11:00 AM PDT 
Call-in Information 
(877) 421-0017 
(770) 615-1378 
Conf ID 986327 
There is no webex planned. 
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/ 


From lohmeyer at t10.org  Sat Mar 29 23:00:51 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 30 Mar 2008 00:00:51 -0600
Subject: Recent T10 documents uploaded since 2008/03/23
Message-ID: <mailman.308.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Results of letter ballot on forwarding SAS-2 to first public review
(by: John Lohmeyer)
T10/08-093r0   Uploaded: 2008/03/28   778109 bytes
ftp://ftp.t10.org/t10/document.08/08-093r0.pdf
Results of letter ballot on forwarding SAS-2 to first public review
(by: John Lohmeyer)
T10/08-093r0   Uploaded: 2008/03/28   329047 bytes
ftp://ftp.t10.org/t10/document.08/08-093r0.txt
OSD-2 CDB Continuations Definition and Usage
(by: Ralph O. Weber)
T10/08-105r1   Uploaded: 2008/03/26   324541 bytes
ftp://ftp.t10.org/t10/document.08/08-105r1.pdf
Limitations of df/dt Specification for SSC Profiles
(by: Guillaume Fortin, Mathieu Gagnon)
T10/08-121r1   Uploaded: 2008/03/26   482822 bytes
ftp://ftp.t10.org/t10/document.08/08-121r1.pdf
Comments on SAS2r14 Physical Layer
(by: Kevin Witt)
T10/08-144r2   Uploaded: 2008/03/27   911655 bytes
ftp://ftp.t10.org/t10/document.08/08-144r2.pdf
FCP-4: Status Report, March 13, 2008
(by: David Peterson)
T10/08-169r1   Uploaded: 2008/03/25   12658 bytes
ftp://ftp.t10.org/t10/document.08/08-169r1.pdf
Fixes for six OSD-2 bugs
(by: Ralph O. Weber)
T10/08-179r1   Uploaded: 2008/03/24   42491 bytes
ftp://ftp.t10.org/t10/document.08/08-179r1.pdf
Fixes for seven OSD-2 bugs
(by: Ralph O. Weber)
T10/08-179r2   Uploaded: 2008/03/27   46266 bytes
ftp://ftp.t10.org/t10/document.08/08-179r2.pdf
Fixes for five OSD-2 bugs
(by: Ralph O. Weber)
T10/08-179r3   Uploaded: 2008/03/29   44063 bytes
ftp://ftp.t10.org/t10/document.08/08-179r3.pdf
SAS-2 Add device slot numbering fields to DISCOVER
(by: Rob Elliott)
T10/08-183r0   Uploaded: 2008/03/28   110936 bytes
ftp://ftp.t10.org/t10/document.08/08-183r0.pdf
SAS-2: Interconnect Requirements
(by: Kevin Butt)
T10/08-186r0   Uploaded: 2008/03/27   19376 bytes
ftp://ftp.t10.org/t10/document.08/08-186r0.pdf
Working Drafts
--------------
(Report generated on 2008/03/30 at 00:00:51)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Sun Mar 30 22:37:45 2008
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 31 Mar 2008 14:37:45 +0900
Subject: Posted: agenda proposal
Message-ID: <mailman.309.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted agenda proposal and other proposals on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Apr08
 Agenda Apr08.doc
 GET_PERFORMANCE.pdf
 RDS_FF.PDF
"GET_PERFORMANCE.pdf" is a proposal for second item of action item 6.1 in
Agenda
Apr08.doc.
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Marian_Lakov at us.xyratex.com  Mon Mar 31 13:38:10 2008
From: Marian_Lakov at us.xyratex.com (Marian Lakov)
Date: Mon, 31 Mar 2008 13:38:10 -0700
Subject: Report LUNs if more than 256 LUNs on the same bus
Message-ID: <mailman.310.1441607336.22514.t10@sandbox.t10.org>

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

Hi,
If a RAID controller presents more than 256 LUNs to a host on the same
bus what is the proper LUN format?
00 00 00 00 00 00 00 00 to 00 00 00 00 00 00 00 FF for the LUNs 0 to 255
and
40 00 00 00 00 00 01 00 to 40 00 00 00 00 00 3F FF for the LUNs above
255
or
40 00 00 00 00 00 00 00 to 40 00 00 00 00 00 3F FF for all the LUNs
Also, for the LUNs above 255, is it possible to use 00 00 00 00 00 00 01
00 to 00 00 00 00 00 003F FF format?
Thanks,
Marian
________________________
Marian Lakov
Systems Engineer
Xyratex
1804 Centre Point Circle, Suite #112
Naperville, IL 60563
Office:  630-364-7600
Fax:	 630-364-7601
marian_lakov at us.xyratex.com
<blocked::mailto:marian_lakov at us.xyratex.com> 
______________________________________________________________________
This email may contain privileged or confidential information, which should
only be used for the purpose for which it was sent by Xyratex. No further
rights or licenses are granted to use such information. If you are not the
intended recipient of this message, please notify the sender by return and
delete it. You may not use, copy, disclose or rely on the information
contained in it.
Internet email is susceptible to data corruption, interception and
unauthorised amendment for which Xyratex does not accept liability. While we
have taken reasonable precautions to ensure that this email is free of
viruses, Xyratex does not accept liability for the presence of any computer
viruses in this email, nor for any losses caused as a result of viruses.
Xyratex Technology Limited (03134912), Registered in England & Wales,
Registered Office, Langstone Road, Havant, Hampshire, PO9 1SA.
The Xyratex group of companies also includes, Xyratex Ltd, registered in
Bermuda, Xyratex International Inc, registered in California, Xyratex
(Malaysia) Sdn Bhd registered in Malaysia, Xyratex Technology (Wuxi) Co Ltd
registered in The People's Republic of China and Xyratex Japan Limited
registered in Japan.


From curtis.ballard at hp.com  Mon Mar 31 13:51:26 2008
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Mon, 31 Mar 2008 20:51:26 +0000
Subject: SSC-3: Late Letter Ballot comment
Message-ID: <mailman.311.1441607336.22514.t10@sandbox.t10.org>

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

Kevin,
I looked into this a bit and came to a different conclusion.
You reference section 4.2.21.6 on Managing keys within the device server and
the section on when to release a set of data encryption parameters which does
not discuss turning off encryption.
I believe the section we need to reference is a little further into 4.2.21.6
at that start of document page 56 in SSC3r04a.pdf where it discusses what to
do when both the ENCRYPTION MODE and the DECRYPTION MODE are set to DISABLE
which is the encryption off condition.
"If a device server processes a Set Data Encryption page with the ENCRYPTION
MODE field set to DISABLE and DECRYPTION MODE field set to DISABLE or RAW,
the physical device shall:
a)release any resources that it had allocated to store data encryption
parameters for the I_T nexus associated with the SECURITY PROTOCOL OUT
command and shall change the contents of all memory containing a key value
associated with the data encryption parameters that are released; and
b)establish a unit attention condition . . ."
The statement "data encryption parameters" was referenced to 4.2.21.8 earlier
in that clause so if we follow that reference we find that virtually all of
the settings that a host can establish are included in the data encryption
parameters including the key instance counter which is tied to locking.  When
both modes are set to DISABLED which is what has to be done to turn
encryption off, then everything in the set of data encryption parameters is
released so all of those values are gone.  If the counter is gone along with
all the other parameters I don't see how the parameters can possibly continue
to be associated with that I_T nexus.
According to my notes we discussed at the last SSC-3 meeting that "LOCK"
should also be included in the data encryption parameters but wasn't due to
an oversight.  If it had been then it would be clear that "LOCK" is gone when
the encryption parameters are released.
I'm concerned that this behavior seems to be inconsistent with the
introduction to 4.2.21.11 which discusses exactly the case of resources being
released and the UA not detected and suggests that LOCK solves the issue.
If the intent is that LOCK persist when the rest of the parameters are
released then I don't think the change is as simple as you suggest.  I think
that we would need to modify 4.2.21.6 to indicate that the key instance
counter is not released with the rest of the parameters if LOCK is set to
one, but instead is incremented.  That way the test described in the section
on locking where a changed key instance counter triggers the CHECK CONDITION
will still work.  We might also have to modify some text describing releasing
resources when limited resources are exhausted to make it clear that
parameters containing a LOCK bit set to one can't be released (I have some
concerns with whether that can be required).  There might also be other
sections that talking about releasing parameters that would need examined.
This one looks to me like it's going to take a proposal to address.
Curtis Ballard
Hewlett Packard
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
Sent: 20 March 2008 21:48
To: t10 at t10.org
Subject: SSC-3: Late Letter Ballot comment
I received communication from an ISV today related to Encryption mode locking
(4.2.21.11).  They were unable to determine if the locking applied when the
data encryption parameters were set such that encryption/decryption is turned
off.  In a close reading this clause refers to "...locked to that set of data
encryption parameters and key instance counter value until a hard reset
condition occurs or another [SPOUT command is received]"
In 4.2.21.6 Managing keys within the physical device, where it describes when
to release a set of data encryption parameters, there is no mention of
turning off encryption.  Therefore, the locking does apply to the saved set
of encryption parameters even when encryption is turned off.  This is indeed
the desired behavior.  However, it is not clear to the casual or novice
standards reader that this is the case.
Proposed Solution (Editorial):
In 4.2.21.11, p2, add a new sentence after s1:
The LOCK bit in the Set Data Encryption page is set to one to lock the I_T
nexus that issued the SECURITY PROTOCOL OUT command to the set of data
encryption parameters established at the completion of the processing of the
command.  A set of data encryption parameters are established and locked even
if the ENCRYPTION MODE is set to DISABLE and the DECRYPTION MODE is set to
DISABLE.
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/


From rsnively at Brocade.COM  Mon Mar 31 14:37:33 2008
From: rsnively at Brocade.COM (Robert Snively)
Date: Mon, 31 Mar 2008 14:37:33 -0700
Subject: [T11.3] Solicitation of technical input, SM-HBA-2
Message-ID: <mailman.312.1441607336.22514.t10@sandbox.t10.org>

The INCITS Fibre Channel (T11) Technical Committee is soliciting
technical contributions to the SM-HBA-2 project.  See www.t11.org,
"documents" T11/06-065v3 for the project proposal defining the
scope of the project.  Contributions will be considered at the
next meeting of the SM-HBA-2 adhoc group during the June 2008
T11 committee meetings.  Clause 3.1 says:
"A standard application programming interface (API) defines 
a programming language by which control can be
specified for certain features of a computing system, 
independently of vendor-specific infrastructure behavior.
A host bus adapter (HBA) is a piece of hardware, typically 
on a host system and sometimes embedded on a RAID
controller or other storage device that interfaces between 
a system and a storage access medium. An HBA and
the medium to which it provides access may also support 
applications other than storage, such as delivery of
Internet Protocol (IP) packets.
The Storage Management Host Bus Adapter Application 
Programming Interface (SM-HBA) standard defines an
API for Fibre Channel and SAS HBAs. The Storage Management 
Host Bus Adapter Application Programming
Interface 2nd generation (SM-HBA-2) project proposal 
recommends the development of additions and enhancements
to SM-HBA to support new features of Fibre Channel and SAS 
that have matured during the development of
SM-HBA. The following capabilities should be included in 
the SM-HBA standard:
a) Administration and operation of Fibre Channel 
	additional N_Port_IDs, also known as N_Port ID Virtualization
	(NPIV);
b) Administration and operation of Fibre Channel Virtual Fabric
connectivity;
c) Administration of fabric security features specified 
	for storage networking media supported by the
	standard;
d) Consider opportunities for administration and operation 
	of HBA virtualization models being developed in
	other standards;
e) Consider opportunities to extend consistent administration 
	and operation to other storage networking
	media;
f) Other capabilities that may fit within the general scope of this
project; 
and
g) Binary compatibility with applications written for one or 
	more predecessor specifications of the standard."
_______________________________________________
T11_3 mailing list
http://mailman.listserve.com/listmanager/listinfo/t11_3


From rsnively at Brocade.COM  Mon Mar 31 14:37:33 2008
From: rsnively at Brocade.COM (Robert Snively)
Date: Mon, 31 Mar 2008 14:37:33 -0700
Subject: Solicitation of technical input, SM-HBA-2
Message-ID: <mailman.313.1441607336.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Robert Snively" <rsnively at Brocade.COM>
*
The INCITS Fibre Channel (T11) Technical Committee is soliciting
technical contributions to the SM-HBA-2 project.  See www.t11.org,
"documents" T11/06-065v3 for the project proposal defining the
scope of the project.  Contributions will be considered at the
next meeting of the SM-HBA-2 adhoc group during the June 2008
T11 committee meetings.  Clause 3.1 says:
"A standard application programming interface (API) defines 
a programming language by which control can be
specified for certain features of a computing system, 
independently of vendor-specific infrastructure behavior.
A host bus adapter (HBA) is a piece of hardware, typically 
on a host system and sometimes embedded on a RAID
controller or other storage device that interfaces between 
a system and a storage access medium. An HBA and
the medium to which it provides access may also support 
applications other than storage, such as delivery of
Internet Protocol (IP) packets.
The Storage Management Host Bus Adapter Application 
Programming Interface (SM-HBA) standard defines an
API for Fibre Channel and SAS HBAs. The Storage Management 
Host Bus Adapter Application Programming
Interface 2nd generation (SM-HBA-2) project proposal 
recommends the development of additions and enhancements
to SM-HBA to support new features of Fibre Channel and SAS 
that have matured during the development of
SM-HBA. The following capabilities should be included in 
the SM-HBA standard:
a) Administration and operation of Fibre Channel 
	additional N_Port_IDs, also known as N_Port ID Virtualization
	(NPIV);
b) Administration and operation of Fibre Channel Virtual Fabric
connectivity;
c) Administration of fabric security features specified 
	for storage networking media supported by the
	standard;
d) Consider opportunities for administration and operation 
	of HBA virtualization models being developed in
	other standards;
e) Consider opportunities to extend consistent administration 
	and operation to other storage networking
	media;
f) Other capabilities that may fit within the general scope of this
project; 
and
g) Binary compatibility with applications written for one or 
	more predecessor specifications of the standard."
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Mon Mar 31 14:43:46 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 31 Mar 2008 14:43:46 -0700
Subject: SAS connection timing
Message-ID: <mailman.314.1441607336.22514.t10@sandbox.t10.org>

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

Is there any requirements related to how long it can take to allow an OPEN 
when in the middle of a SCSI transfer?
e.g., Read command
target tries to OPEN a connection with the initiator port to transfer a 
frame.	The initiator port doesn't accept the OPEN.  How long is can the 
initiator port not accept the OPEN (e.g., to perform flow throttling)?
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


From Paul.Entzel at lsi.com  Mon Mar 31 14:55:14 2008
From: Paul.Entzel at lsi.com (Entzel, Paul)
Date: Mon, 31 Mar 2008 15:55:14 -0600
Subject: SSC-3: Late Letter Ballot comment
Message-ID: <mailman.315.1441607336.22514.t10@sandbox.t10.org>

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

Hello Curtis,
The concept of LOCK was to allow an I_T nexus to create a fixed
association with a particular set of data encryption parameters at a
specific generation (key instance counter).  This association is saved
with the I_T nexus (see subclause 4.2.21.7) not with the set of data
encryption parameters because more than one I_T nexus can be associated
with a set of data encryption parameters (one as the creator, others
using the PUBLIC scope).  It was not an oversight to not include the
lock bit in the data encryption parameters structure, it doesn't belong
there.	Consider the example where I_T nexus A sends a SPOUT command to
create a set of data encryption parameters with a scope of ALL I_T_NEXUS
but does not set the LOCK bit, then I_T nexus B sends a SPOUT command
with a scope of PUBLIC with the LOCK bit set to 1.  In this example, A
is not locked to the parameters but B is.  What would you put in the
lock parameter if it was part of the set of data encryption parameters?
You may want to consider fixing the problem by introducing the concept
of a master key instance counter in 4.2.41.10 that is not associated
with any set of data encryption parameters.  It would be incremented and
inserted into the set of data encryption parameters each time one is
created.  You would also need to modify the test in 4.2.21.11 such that
a lock violation occurs if the I_T nexus is locked and the data
encryption parameters have been released.
Paul Entzel
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ballard,
Curtis C (StorageWorks)
Sent: Monday, March 31, 2008 2:51 PM
To: 't10 at t10.org'
Subject: RE: SSC-3: Late Letter Ballot comment
Kevin,
I looked into this a bit and came to a different conclusion.
You reference section 4.2.21.6 on Managing keys within the device server
and the section on when to release a set of data encryption parameters
which does not discuss turning off encryption.
I believe the section we need to reference is a little further into
4.2.21.6 at that start of document page 56 in SSC3r04a.pdf where it
discusses what to do when both the ENCRYPTION MODE and the DECRYPTION
MODE are set to DISABLE which is the encryption off condition.
"If a device server processes a Set Data Encryption page with the
ENCRYPTION MODE field set to DISABLE and DECRYPTION MODE field set to
DISABLE or RAW, the physical device shall: 
a)release any resources that it had allocated to store data encryption
parameters for the I_T nexus associated with the SECURITY PROTOCOL OUT
command and shall change the contents of all memory containing a key
value associated with the data encryption parameters that are released;
and
b)establish a unit attention condition . . ."
The statement "data encryption parameters" was referenced to 4.2.21.8
earlier in that clause so if we follow that reference we find that
virtually all of the settings that a host can establish are included in
the data encryption parameters including the key instance counter which
is tied to locking.  When both modes are set to DISABLED which is what
has to be done to turn encryption off, then everything in the set of
data encryption parameters is released so all of those values are gone.
If the counter is gone along with all the other parameters I don't see
how the parameters can possibly continue to be associated with that I_T
nexus.
According to my notes we discussed at the last SSC-3 meeting that "LOCK"
should also be included in the data encryption parameters but wasn't due
to an oversight.  If it had been then it would be clear that "LOCK" is
gone when the encryption parameters are released.
I'm concerned that this behavior seems to be inconsistent with the
introduction to 4.2.21.11 which discusses exactly the case of resources
being released and the UA not detected and suggests that LOCK solves the
issue.
If the intent is that LOCK persist when the rest of the parameters are
released then I don't think the change is as simple as you suggest.  I
think that we would need to modify 4.2.21.6 to indicate that the key
instance counter is not released with the rest of the parameters if LOCK
is set to one, but instead is incremented.  That way the test described
in the section on locking where a changed key instance counter triggers
the CHECK CONDITION will still work.  We might also have to modify some
text describing releasing resources when limited resources are exhausted
to make it clear that parameters containing a LOCK bit set to one can't
be released (I have some concerns with whether that can be required).
There might also be other sections that talking about releasing
parameters that would need examined.
This one looks to me like it's going to take a proposal to address.
Curtis Ballard
Hewlett Packard
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: 20 March 2008 21:48
To: t10 at t10.org
Subject: SSC-3: Late Letter Ballot comment
I received communication from an ISV today related to Encryption mode
locking (4.2.21.11).  They were unable to determine if the locking
applied when the data encryption parameters were set such that
encryption/decryption is turned off.  In a close reading this clause
refers to "...locked to that set of data encryption parameters and key
instance counter value until a hard reset condition occurs or another
[SPOUT command is received]" 
In 4.2.21.6 Managing keys within the physical device, where it describes
when to release a set of data encryption parameters, there is no mention
of turning off encryption.  Therefore, the locking does apply to the
saved set of encryption parameters even when encryption is turned off.
This is indeed the desired behavior.  However, it is not clear to the
casual or novice standards reader that this is the case. 
Proposed Solution (Editorial): 
In 4.2.21.11, p2, add a new sentence after s1: 
The LOCK bit in the Set Data Encryption page is set to one to lock the
I_T nexus that issued the SECURITY PROTOCOL OUT command to the set of
data encryption parameters established at the completion of the
processing of the command.  A set of data encryption parameters are
established and locked even if the ENCRYPTION MODE is set to DISABLE and
the DECRYPTION MODE is set to DISABLE. 
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/ 


From kdbutt at us.ibm.com  Mon Mar 31 15:07:30 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 31 Mar 2008 15:07:30 -0700
Subject: SSC-3: Late Letter Ballot comment
Message-ID: <mailman.316.1441607336.22514.t10@sandbox.t10.org>

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

Curtis,
I agree that it is probably not as simple as what I suggested.	Clearly 
you have pointed out conflicting interpretations.  But you also pointed 
out that if the intent was to have the LOCK protect against missed UA's 
(and I confirm that the intent of LOCK is indeed to protect against 
mission UA's) then we have some issues to work through.
Dave,
Please list this as a technical comment that needs a proposal for 
resolution.
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/ 
"Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com> 
Sent by: owner-t10 at t10.org
03/31/2008 01:51 PM
To
"'t10 at t10.org'" <t10 at t10.org>
cc
Subject
RE: SSC-3: Late Letter Ballot comment
Kevin,
I looked into this a bit and came to a different conclusion.
You reference section 4.2.21.6 on Managing keys within the device server 
and the section on when to release a set of data encryption parameters 
which does not discuss turning off encryption.
I believe the section we need to reference is a little further into 
4.2.21.6 at that start of document page 56 in SSC3r04a.pdf where it 
discusses what to do when both the ENCRYPTION MODE and the DECRYPTION MODE 
are set to DISABLE which is the encryption off condition.
"If a device server processes a Set Data Encryption page with the 
ENCRYPTION MODE field set to DISABLE and DECRYPTION MODE field set to 
DISABLE or RAW, the physical device shall: 
a)release any resources that it had allocated to store data encryption 
parameters for the I_T nexus associated with the SECURITY PROTOCOL OUT 
command and shall change the contents of all memory containing a key value 
associated with the data encryption parameters that are released; and
b)establish a unit attention condition . . ."
The statement "data encryption parameters" was referenced to 4.2.21.8 
earlier in that clause so if we follow that reference we find that 
virtually all of the settings that a host can establish are included in 
the data encryption parameters including the key instance counter which is 
tied to locking.  When both modes are set to DISABLED which is what has to 
be done to turn encryption off, then everything in the set of data 
encryption parameters is released so all of those values are gone.  If the 
counter is gone along with all the other parameters I don't see how the 
parameters can possibly continue to be associated with that I_T nexus.
According to my notes we discussed at the last SSC-3 meeting that "LOCK" 
should also be included in the data encryption parameters but wasn't due 
to an oversight.  If it had been then it would be clear that "LOCK" is 
gone when the encryption parameters are released.
I'm concerned that this behavior seems to be inconsistent with the 
introduction to 4.2.21.11 which discusses exactly the case of resources 
being released and the UA not detected and suggests that LOCK solves the 
issue.
If the intent is that LOCK persist when the rest of the parameters are 
released then I don't think the change is as simple as you suggest.  I 
think that we would need to modify 4.2.21.6 to indicate that the key 
instance counter is not released with the rest of the parameters if LOCK 
is set to one, but instead is incremented.  That way the test described in 
the section on locking where a changed key instance counter triggers the 
CHECK CONDITION will still work.  We might also have to modify some text 
describing releasing resources when limited resources are exhausted to 
make it clear that parameters containing a LOCK bit set to one can't be 
released (I have some concerns with whether that can be required).  There 
might also be other sections that talking about releasing parameters that 
would need examined.
This one looks to me like it's going to take a proposal to address.
Curtis Ballard
Hewlett Packard
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: 20 March 2008 21:48
To: t10 at t10.org
Subject: SSC-3: Late Letter Ballot comment
I received communication from an ISV today related to Encryption mode 
locking (4.2.21.11).  They were unable to determine if the locking applied 
when the data encryption parameters were set such that 
encryption/decryption is turned off.  In a close reading this clause 
refers to "...locked to that set of data encryption parameters and key 
instance counter value until a hard reset condition occurs or another 
[SPOUT command is received]" 
In 4.2.21.6 Managing keys within the physical device, where it describes 
when to release a set of data encryption parameters, there is no mention 
of turning off encryption.  Therefore, the locking does apply to the saved 
set of encryption parameters even when encryption is turned off.  This is 
indeed the desired behavior.  However, it is not clear to the casual or 
novice standards reader that this is the case. 
Proposed Solution (Editorial): 
In 4.2.21.11, p2, add a new sentence after s1: 
The LOCK bit in the Set Data Encryption page is set to one to lock the I_T 
nexus that issued the SECURITY PROTOCOL OUT command to the set of data 
encryption parameters established at the completion of the processing of 
the command.  A set of data encryption parameters are established and 
locked even if the ENCRYPTION MODE is set to DISABLE and the DECRYPTION 
MODE is set to DISABLE. 
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/ 


From curtis.ballard at hp.com  Mon Mar 31 15:20:30 2008
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Mon, 31 Mar 2008 22:20:30 +0000
Subject: SSC-3: Late Letter Ballot comment
Message-ID: <mailman.317.1441607336.22514.t10@sandbox.t10.org>

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

Thanks Kevin,
I'm sure we can iron this out with some discussion in the working group.
Curtis
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Monday, March 31, 2008 4:08 PM
To: Ballard, Curtis C (StorageWorks); Peterson, Dave
Cc: 't10 at t10.org'
Subject: RE: SSC-3: Late Letter Ballot comment
Curtis,
I agree that it is probably not as simple as what I suggested.	Clearly you
have pointed out conflicting interpretations.  But you also pointed out that
if the intent was to have the LOCK protect against missed UA's (and I confirm
that the intent of LOCK is indeed to protect against mission UA's) then we
have some issues to work through.
Dave,
Please list this as a technical comment that needs a proposal for resolution.
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/
"Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
Sent by: owner-t10 at t10.org
03/31/2008 01:51 PM
To
"'t10 at t10.org'" <t10 at t10.org>
cc
Subject
RE: SSC-3: Late Letter Ballot comment
Kevin,
I looked into this a bit and came to a different conclusion.
You reference section 4.2.21.6 on Managing keys within the device server and
the section on when to release a set of data encryption parameters which does
not discuss turning off encryption.
I believe the section we need to reference is a little further into 4.2.21.6
at that start of document page 56 in SSC3r04a.pdf where it discusses what to
do when both the ENCRYPTION MODE and the DECRYPTION MODE are set to DISABLE
which is the encryption off condition.
"If a device server processes a Set Data Encryption page with the ENCRYPTION
MODE field set to DISABLE and DECRYPTION MODE field set to DISABLE or RAW,
the physical device shall:
a)release any resources that it had allocated to store data encryption
parameters for the I_T nexus associated with the SECURITY PROTOCOL OUT
command and shall change the contents of all memory containing a key value
associated with the data encryption parameters that are released; and
b)establish a unit attention condition . . ."
The statement "data encryption parameters" was referenced to 4.2.21.8 earlier
in that clause so if we follow that reference we find that virtually all of
the settings that a host can establish are included in the data encryption
parameters including the key instance counter which is tied to locking.  When
both modes are set to DISABLED which is what has to be done to turn
encryption off, then everything in the set of data encryption parameters is
released so all of those values are gone.  If the counter is gone along with
all the other parameters I don't see how the parameters can possibly continue
to be associated with that I_T nexus.
According to my notes we discussed at the last SSC-3 meeting that "LOCK"
should also be included in the data encryption parameters but wasn't due to
an oversight.  If it had been then it would be clear that "LOCK" is gone when
the encryption parameters are released.
I'm concerned that this behavior seems to be inconsistent with the
introduction to 4.2.21.11 which discusses exactly the case of resources being
released and the UA not detected and suggests that LOCK solves the issue.
If the intent is that LOCK persist when the rest of the parameters are
released then I don't think the change is as simple as you suggest.  I think
that we would need to modify 4.2.21.6 to indicate that the key instance
counter is not released with the rest of the parameters if LOCK is set to
one, but instead is incremented.  That way the test described in the section
on locking where a changed key instance counter triggers the CHECK CONDITION
will still work.  We might also have to modify some text describing releasing
resources when limited resources are exhausted to make it clear that
parameters containing a LOCK bit set to one can't be released (I have some
concerns with whether that can be required).  There might also be other
sections that talking about releasing parameters that would need examined.
This one looks to me like it's going to take a proposal to address.
Curtis Ballard
Hewlett Packard
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
Sent: 20 March 2008 21:48
To: t10 at t10.org
Subject: SSC-3: Late Letter Ballot comment
I received communication from an ISV today related to Encryption mode locking
(4.2.21.11).  They were unable to determine if the locking applied when the
data encryption parameters were set such that encryption/decryption is turned
off.  In a close reading this clause refers to "...locked to that set of data
encryption parameters and key instance counter value until a hard reset
condition occurs or another [SPOUT command is received]"
In 4.2.21.6 Managing keys within the physical device, where it describes when
to release a set of data encryption parameters, there is no mention of
turning off encryption.  Therefore, the locking does apply to the saved set
of encryption parameters even when encryption is turned off.  This is indeed
the desired behavior.  However, it is not clear to the casual or novice
standards reader that this is the case.
Proposed Solution (Editorial):
In 4.2.21.11, p2, add a new sentence after s1:
The LOCK bit in the Set Data Encryption page is set to one to lock the I_T
nexus that issued the SECURITY PROTOCOL OUT command to the set of data
encryption parameters established at the completion of the processing of the
command.  A set of data encryption parameters are established and locked even
if the ENCRYPTION MODE is set to DISABLE and the DECRYPTION MODE is set to
DISABLE.
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/


From kdbutt at us.ibm.com  Mon Mar 31 16:20:55 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 31 Mar 2008 16:20:55 -0700
Subject: SSC-3: Late Letter Ballot comment
Message-ID: <mailman.318.1441607336.22514.t10@sandbox.t10.org>

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

Paul,
Just to be clear, the LOCK bit is only associated with the specific I_T 
nexus on which the SPOUT command was received with the LOCK bit set.  In 
your example A is not locked to the parameters (the parameters being those 
set for I_T nexus A) but B is locked to the parameters (those parameters 
set for I_T nexus B - which are different parameters than those that are 
set for I_T nexus A).
The key point here is that the encryption parameters are set per I_T 
nexus.	Any changes that occur on other I_T nexuses do not change the 
parameters in another I_T nexus.  This means the LOCK bit only helps the 
I_T nexus that set the encryption parameters with the LOCK bit set.
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/ 
"Entzel, Paul" <Paul.Entzel at lsi.com> 
Sent by: owner-t10 at t10.org
03/31/2008 02:55 PM
To
"Ballard, Curtis C \(StorageWorks\)" <curtis.ballard at hp.com>, 
<t10 at t10.org>
cc
Subject
RE: SSC-3: Late Letter Ballot comment
Hello Curtis,
The concept of LOCK was to allow an I_T nexus to create a fixed 
association with a particular set of data encryption parameters at a 
specific generation (key instance counter).  This association is saved 
with the I_T nexus (see subclause 4.2.21.7) not with the set of data 
encryption parameters because more than one I_T nexus can be associated 
with a set of data encryption parameters (one as the creator, others using 
the PUBLIC scope).  It was not an oversight to not include the lock bit in 
the data encryption parameters structure, it doesn't belong there. 
Consider the example where I_T nexus A sends a SPOUT command to create a 
set of data encryption parameters with a scope of ALL I_T_NEXUS but does 
not set the LOCK bit, then I_T nexus B sends a SPOUT command with a scope 
of PUBLIC with the LOCK bit set to 1.  In this example, A is not locked to 
the parameters but B is.  What would you put in the lock parameter if it 
was part of the set of data encryption parameters?
You may want to consider fixing the problem by introducing the concept of 
a master key instance counter in 4.2.41.10 that is not associated with any 
set of data encryption parameters.  It would be incremented and inserted 
into the set of data encryption parameters each time one is created.  You 
would also need to modify the test in 4.2.21.11 such that a lock violation 
occurs if the I_T nexus is locked and the data encryption parameters have 
been released.
Paul Entzel
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ballard, 
Curtis C (StorageWorks)
Sent: Monday, March 31, 2008 2:51 PM
To: 't10 at t10.org'
Subject: RE: SSC-3: Late Letter Ballot comment
Kevin,
I looked into this a bit and came to a different conclusion.
You reference section 4.2.21.6 on Managing keys within the device server 
and the section on when to release a set of data encryption parameters 
which does not discuss turning off encryption.
I believe the section we need to reference is a little further into 
4.2.21.6 at that start of document page 56 in SSC3r04a.pdf where it 
discusses what to do when both the ENCRYPTION MODE and the DECRYPTION MODE 
are set to DISABLE which is the encryption off condition.
"If a device server processes a Set Data Encryption page with the 
ENCRYPTION MODE field set to DISABLE and DECRYPTION MODE field set to 
DISABLE or RAW, the physical device shall: 
a)release any resources that it had allocated to store data encryption 
parameters for the I_T nexus associated with the SECURITY PROTOCOL OUT 
command and shall change the contents of all memory containing a key value 
associated with the data encryption parameters that are released; and
b)establish a unit attention condition . . ."
The statement "data encryption parameters" was referenced to 4.2.21.8 
earlier in that clause so if we follow that reference we find that 
virtually all of the settings that a host can establish are included in 
the data encryption parameters including the key instance counter which is 
tied to locking.  When both modes are set to DISABLED which is what has to 
be done to turn encryption off, then everything in the set of data 
encryption parameters is released so all of those values are gone.  If the 
counter is gone along with all the other parameters I don't see how the 
parameters can possibly continue to be associated with that I_T nexus.
According to my notes we discussed at the last SSC-3 meeting that "LOCK" 
should also be included in the data encryption parameters but wasn't due 
to an oversight.  If it had been then it would be clear that "LOCK" is 
gone when the encryption parameters are released.
I'm concerned that this behavior seems to be inconsistent with the 
introduction to 4.2.21.11 which discusses exactly the case of resources 
being released and the UA not detected and suggests that LOCK solves the 
issue.
If the intent is that LOCK persist when the rest of the parameters are 
released then I don't think the change is as simple as you suggest.  I 
think that we would need to modify 4.2.21.6 to indicate that the key 
instance counter is not released with the rest of the parameters if LOCK 
is set to one, but instead is incremented.  That way the test described in 
the section on locking where a changed key instance counter triggers the 
CHECK CONDITION will still work.  We might also have to modify some text 
describing releasing resources when limited resources are exhausted to 
make it clear that parameters containing a LOCK bit set to one can't be 
released (I have some concerns with whether that can be required).  There 
might also be other sections that talking about releasing parameters that 
would need examined.
This one looks to me like it's going to take a proposal to address.
Curtis Ballard
Hewlett Packard
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: 20 March 2008 21:48
To: t10 at t10.org
Subject: SSC-3: Late Letter Ballot comment
I received communication from an ISV today related to Encryption mode 
locking (4.2.21.11).  They were unable to determine if the locking applied 
when the data encryption parameters were set such that 
encryption/decryption is turned off.  In a close reading this clause 
refers to "...locked to that set of data encryption parameters and key 
instance counter value until a hard reset condition occurs or another 
[SPOUT command is received]" 
In 4.2.21.6 Managing keys within the physical device, where it describes 
when to release a set of data encryption parameters, there is no mention 
of turning off encryption.  Therefore, the locking does apply to the saved 
set of encryption parameters even when encryption is turned off.  This is 
indeed the desired behavior.  However, it is not clear to the casual or 
novice standards reader that this is the case. 
Proposed Solution (Editorial): 
In 4.2.21.11, p2, add a new sentence after s1: 
The LOCK bit in the Set Data Encryption page is set to one to lock the I_T 
nexus that issued the SECURITY PROTOCOL OUT command to the set of data 
encryption parameters established at the completion of the processing of 
the command.  A set of data encryption parameters are established and 
locked even if the ENCRYPTION MODE is set to DISABLE and the DECRYPTION 
MODE is set to DISABLE. 
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/