From kdbutt at us.ibm.com  Thu Nov  1 10:48:29 2012
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 1 Nov 2012 10:48:29 -0700
Subject: 12-402 feedback
Message-ID: <mailman.317.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211010_f.htm">HTML-formatted message</a>

Gerry,
IBM has reviewed proposal 12-402r0.  While the goal of being able to 
report other errors seems good, we believe that it would better be 
accomplished by using a different page for non-background errors (e.g., 
SCSI Foreground Media Errors log page) and leave the existing background 
error page alone.  We believe it is important to be able to distinguish an 
error between background and foreground operations.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From gerry.houlder at seagate.com  Thu Nov  1 11:31:08 2012
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Thu, 1 Nov 2012 13:31:08 -0500
Subject: 12-402 feedback
Message-ID: <mailman.318.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211011_f.htm">HTML-formatted message</a>

I agree with the need for that distinction. That is why there is a new
REASSIGN STATUS code value to distinguish foreground unrecovered errors
|from background unrecovered errors. I did not bother to add other code
values to distinguish foreground recovered errors because once they are
recovered there is no further action required of a host and the issue
becomes moot.
Also keep in mind that all foreground recovered errors are supposed to be
reported to the host as either a current error (the CHECK CONDITION status
is returned on the command with the unrecovered error) or a deferred error.
Adding foreground unrecovered errors to this list provides a convenience to
the host in that there is only on place that has to be examined to find all
of the unrecovered error sites that the device server knows about,
regardless of how the errors were detected.
I do concede that there might be different categories of foreground
unrecovered errors that could be accounted for. This would suggest the
possible need for two or more REASSIGN STATUS codes to distinguish
different foreground error sources. I am open to suggestions for such
additional categories but don't see any useful distinctions at the moment.
On Thu, Nov 1, 2012 at 12:48 PM, Kevin D Butt <kdbutt at us.ibm.com> wrote:
> Gerry,
>
> IBM has reviewed proposal 12-402r0.  While the goal of being able to
> report other errors seems good, we believe that it would better be
> accomplished by using a different page for non-background errors (e.g.,
> SCSI Foreground Media Errors log page) and leave the existing background
> error page alone.  We believe it is important to be able to distinguish an
> error between background and foreground operations.
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> Data Protection & Retention
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 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  Thu Nov  1 12:15:31 2012
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 1 Nov 2012 12:15:31 -0700
Subject: 12-402 feedback
Message-ID: <mailman.319.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211012_f.htm">HTML-formatted message</a>

Gerry,
While there may be a new code, this proposal requires existing software to 
be modified.  That is not something that IBM wants to sign up for.
thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 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:	Gerry Houlder <gerry.houlder at seagate.com>
To:	Kevin D Butt/Tucson/IBM at IBMUS, 
Cc:	T10 Reflector <t10 at t10.org>
Date:	11/01/2012 11:32 AM
Subject:	Re: 12-402 feedback
I agree with the need for that distinction. That is why there is a new 
REASSIGN STATUS code value to distinguish foreground unrecovered errors 
|from background unrecovered errors. I did not bother to add other code 
values to distinguish foreground recovered errors because once they are 
recovered there is no further action required of a host and the issue 
becomes moot.
Also keep in mind that all foreground recovered errors are supposed to be 
reported to the host as either a current error (the CHECK CONDITION status 
is returned on the command with the unrecovered error) or a deferred 
error. Adding foreground unrecovered errors to this list provides a 
convenience to the host in that there is only on place that has to be 
examined to find all of the unrecovered error sites that the device server 
knows about, regardless of how the errors were detected.
I do concede that there might be different categories of foreground 
unrecovered errors that could be accounted for. This would suggest the 
possible need for two or more REASSIGN STATUS codes to distinguish 
different foreground error sources. I am open to suggestions for such 
additional categories but don't see any useful distinctions at the moment.
On Thu, Nov 1, 2012 at 12:48 PM, Kevin D Butt <kdbutt at us.ibm.com> wrote:
Gerry, 
IBM has reviewed proposal 12-402r0.  While the goal of being able to 
report other errors seems good, we believe that it would better be 
accomplished by using a different page for non-background errors (e.g., 
SCSI Foreground Media Errors log page) and leave the existing background 
error page alone.  We believe it is important to be able to distinguish an 
error between background and foreground operations. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 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 Nov  3 23:01:22 2012
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 4 Nov 2012 00:01:22 -0600
Subject: Recent T10 documents uploaded since 2012/10/28
Message-ID: <mailman.320.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC-3 LBP Log page example annex
(by: Frederick Knight)
T10/11-030r2   Uploaded: 2012/11/02   208863 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-030r2.pdf
PQI Letter Ballot Comments Incorporated in PQI-R06
(by: Ie-Wei Njoo)
T10/12-373r3   Uploaded: 2012/11/02   7675484 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-373r3.fdf
PQI Letter Ballot Comments Incorporated in PQI-R06
(by: Ie-Wei Njoo)
T10/12-373r3   Uploaded: 2012/11/02   85633 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-373r3.pdf
PQI Letter Ballot Comments Incorporated in PQI-R06
(by: Ie-Wei Njoo)
T10/12-373r3   Uploaded: 2012/11/02   1014784 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-373r3.xls
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r2   Uploaded: 2012/10/29   2891039 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r2.fdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r2   Uploaded: 2012/10/29   6790077 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r2.pdf
SPL-3:Management ECM/Application Client connection close request
(by: George Penokie)
T10/12-380r2   Uploaded: 2012/10/29   417884 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-380r2.pdf
Meeting Announcement: T10 Week Jan 7-11, 2013 -- Irvine, CA
(by: Curtis Stevens)
T10/12-397r1   Uploaded: 2012/10/31   60210 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-397r1.pdf
Minutes of SOP-PQI Working Group - 10-11 October 2012
(by: Rob Elliott)
T10/12-407r0   Uploaded: 2012/10/29   127784 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-407r0.pdf
SBC-3 Model Logical Unit operations as classes
(by: Rob Elliott)
T10/12-417r2   Uploaded: 2012/10/31   134032 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-417r2.pdf
SAM-5 SBC-4 SPC-5 Time Priority
(by: Dan Colegrove)
T10/12-425r0   Uploaded: 2012/10/31   107466 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-425r0.pdf
SOP PQI Class diagrams for PQI domains
(by: Rob Elliott)
T10/12-426r0   Uploaded: 2012/10/30   157254 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-426r0.pdf
SBC-4 Define new background scan status value
(by: Gerald Houlder)
T10/12-427r0   Uploaded: 2012/10/29   52942 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-427r0.pdf
SPL-3 Legacy zone group administrator management
(by: Tim Symons)
T10/12-428r0   Uploaded: 2012/10/29   211843 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-428r0.pdf
SPL-3 STP CONTINUE AWT bit description clarification
(by: Tim Symons)
T10/12-429r0   Uploaded: 2012/10/29   34106 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-429r0.pdf
SAM-5 SPC-4 Add Peripheral Device class under Logical Unit
(by: Rob Elliott)
T10/12-434r0   Uploaded: 2012/11/02   177727 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-434r0.pdf
SAS-3: Passive Cable S-parameter Limit Proposal
(by: Darian Schulz)
T10/12-435r0   Uploaded: 2012/11/01   2281286 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-435r0.pdf
SSC-4: Response to LB #IBM-36 (Append-only & BOP)
(by: Kevin Butt)
T10/12-439r0   Uploaded: 2012/11/02   46710 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-439r0.pdf
Working Drafts
--------------
PCIe(r) architecture Queuing Interface (PQI)
(Editor: Ie-Wei Njoo)
 Rev: 06d      Uploaded: 2012/11/02   1977201 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=pqi-r06d.pdf
SCSI Block Commands - 3 (SBC-3)
(Editor: Mark Evans)
 Rev: 33       Uploaded: 2012/10/31   2269721 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r33.pdf
(Report generated on 2012/11/04 at 00:01:22)
*
* 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 Nov  6 11:49:18 2012
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 6 Nov 2012 12:49:18 -0700
Subject: Conference call for SCSI LU Conglomerates
Message-ID: <mailman.321.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211060_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211060_nameless-296-3.txt">nameless-296-3.txt</a>

When: Monday, November 12, 2012 9:00 AM-11:00 AM (GMT-06:00) Central Time (US
& Canada).
Note: The GMT offset above does not reflect daylight saving time adjustments.
*~*~*~*~*~*~*~*~*~*
George Penokie invites you to an online meeting using WebEx.
Meeting Number: 808 154 971
Meeting Password: scsiata
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to
https://lsi-corp.webex.com/lsi-corp/j.php?J=808154971&PW=NNmE3ZDZiNjI1
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: scsiata
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Audio conference information
-------------------------------------------------------
Use the information below to connect:
Toll-free: +1 (866) 214-7945
Toll: +1 (702) 696-4029
Participant code: 5073289017
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From kdbutt at us.ibm.com  Tue Nov  6 12:20:56 2012
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 6 Nov 2012 13:20:56 -0700
Subject: IBM's response to 12-405r0 SAM-5: UA and task set interaction
 claraification
Message-ID: <mailman.322.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211061_f.htm">HTML-formatted message</a>

Fred,
Please see our responses in red.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 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:	"Knight, Frederick" <Frederick.Knight at netapp.com>
To:	Kevin D Butt/Tucson/IBM at IBMUS, 
Date:	10/17/2012 11:40 AM
Subject:	RE: IBM's response to 12-405r0 SAM-5: UA and task set 
interaction claraification
I honestly don?t understand some of your comments.  My questions are 
below:
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Monday, October 15, 2012 7:47 PM
To: T10 Reflector; James P Allen
Subject: IBM's response to 12-405r0 SAM-5: UA and task set interaction 
claraification
IBM has comments related to 12-405r0 
SAM-5: UA and task set interaction claraification
(by: Frederick Knight)
T10/12-405r0   Uploaded: 2012/10/08   175917 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-405r0.pdf
The current SCSI standard can be interpreted in multiple ways for UA 
29/00. IBM would agree that clarification might be useful here providing 
we can agree on what that should be. However IBM does not think that 
clarification should be the current proposal in 12-405r0. 
Under this proposal if a lun has a UA 29/00 pending, multiple tasks would 
be allowed to be accepted by that lun. The first task processed (enabled) 
would fail with UA 29/00. The subsequent ones would be governed by QErr 
bit settings.
Actually, that is nothing new in this proposal.  That statement is already 
true.
IBM doesn't agree with this. There appears to be ambiguity in the standard 
on how/when tasks are placed in the task set in relation to pending 
errors.  In SAM section 5.4.2.3 (SCSI Command Received SCSI transport 
protocol service indication) it specifies the task router passes a task to 
the task manager via SCSI Command Received interface. This interface only 
allows one task at a time to passed to the task manager. There is not an 
interface to pass multiple tasks at once to the task manager. Thus the 
task router must call the SCSI Command Received for each task it sends to 
the task manager. The task router needs to wait for the SCSI Command 
Received to complete before it can send another task to the task manager 
via the SCSI Command Received. From section 8.8 (Command state 
transitions) one would infer the task received by the task manager from 
the SCSI command Received interface would go immediately into the dormant 
state. However in the case in point (a Unit Attention 29/00 pending with 
no other tasks in the task set), one could also infer that this task does 
the S1:S2 transition immediately after it goes into the dormant state. 
When that happens it should do the S2:S4 transition immediately.  
Thus the ambiguity in the standard is what the relation between SCSI 
Command Received (of section 5.6) and command state transition (of section 
8.8) when the task set is empty. Does it ever complete the full state 
transition (when pending errors exist for empty task set) before the SCSI 
Command Receive returns to the task router. This goes to the larger 
question of whether it is possible for multiple commands can be accepted 
into the task set before any of them are completed/aborted with Unit 
Attention 29/00.
If the SCSI Command Received led to an immediate Command Aborted in the 
Unit Attention 29/00. Any subsequent task issued by the task router would 
then be governed by QErr and NACA.
While the update to section 5.14 does not say explicit rule out the IBM 
Initiator preferred interpretation (i.e SCSI Command Received for empty 
task set results in immediate Unit Attention 29/00 before other task can 
be issued by the task router to the task manager), it gives greater 
credibility/emphasis on an alternate interpretation.  Future SCSI updates 
could then leverage this update as way to clarify the above ambiguity to 
the alternate interpretation.
This seems problematic for a number of situations where a device's state 
may have substantially changed thus compromising data from the initiator 
perspective. Thus the subsequent tasks may be processed from a device that 
is in a questionable state (i.e. loss of reservations and thus no 
synchronization of read/writes with other hosts, difference in mode 
settings etc). 
What you have described is how QERR=00b works.	If QERR is set to 00b then 
if ACA is being used, everything stops to wait for the host to do whatever 
it wants for cleanup/recovery and if ACA is not being used, then 
everything just proceeds (with all the problems you?ve mentioned).  There 
is nothing in this proposal that changes that operation.  So, I don?t 
understand why this is a problem?
See above description of SAM ambiguity.  The standards ambiguity is beyond 
the semantics of QErr.	
A way to avoid the above issue would be to have the device support QErr = 
x1 settings. This though is problematic, since a device may not support 
this setting.
QERR=x1 is just a way to control where cleanup/recovery actions take place 
(QERR=x1 means the device server does the cleanup and QERR=x0 means the 
host does the cleanup).  And, BTW ? everything described in the proposal 
will still occur.  AFTER the cleanup finishes (it does not matter what 
QERR is set to; no matter who does the cleanup), the UA 29/00 will still 
be queued for OTHER initiators, and so when those initiators finally have 
the UA delivered, it no longer reflects the current state of the device 
(which is all that this proposal is describing).  UAs do not describe a 
current state; they are an indication of a previous event.
As mentioned above QErr=x1 does not clarify the above ambiguity it just 
works around the issue.
A more robust solution (from the initiator's perspective) is for the first 
command to be failed immediately with UA 29/00 before other commands are 
accepted. The subsequent commands would then be governed by whether the 
faulted command had the NACA=1 bit set. If so then subsequent commands 
would be failed with ACA ACTIVE status. This is how some of IBM's 
engineers interpret the standard. Based on how SCSI evolved, IBM thinks 
that this is more consistent with the original intent of the standard. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 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.stevens at wdc.com  Tue Nov  6 16:03:13 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Wed, 7 Nov 2012 00:03:13 +0000
Subject: SCSI Feature Sets (12-414)
Message-ID: <mailman.323.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211062_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211062_nameless-3176-3.txt">nameless-3176-3.txt</a>

CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 741 526 907
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=741526907
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-877-860-3058  (US/Canada)
Call-in number (Premiere): 1-719-867-1571  (US/Canada)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9920374743&num=1877-860
-3058&num2=1719-867-1571
Attendee access code: 992 037 4743
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From lohmeyer at t10.org  Wed Nov  7 10:21:54 2012
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 07 Nov 2012 11:21:54 -0700
Subject: Draft CAP minutes posted
Message-ID: <mailman.324.1441607379.22528.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 November 5-6, 2012 CAP working group meeting are
available at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-430r0.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  Wed Nov  7 12:58:16 2012
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 07 Nov 2012 13:58:16 -0700
Subject: Draft SAS Protocol minutes posted
Message-ID: <mailman.325.1441607379.22528.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 November 7, 2012 SAS Protocol working group meeting
are available at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-431r0.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 curtis.stevens at wdc.com  Thu Nov  8 14:26:08 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Nov 2012 22:26:08 +0000
Subject: SOPQI Letter Ballot Comment  Resolution
Message-ID: <mailman.326.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211080_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211080_nameless-3832-3.txt">nameless-3832-3.txt</a>

Date: 12-Nov-2012
Time: 12:30pm PT
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 747 266 562
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=747266562
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-866-546-3377  (US)
Call-in number (Premiere): 1-719-234-7872  (US)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546
-3377&num2=1719-234-7872
Attendee access code: 982 762 9443
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From curtis.stevens at wdc.com  Thu Nov  8 14:28:04 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Nov 2012 22:28:04 +0000
Subject: SOPQI Letter Ballot Comment Resolution
Message-ID: <mailman.327.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211081_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211081_nameless-3832-6.txt">nameless-3832-6.txt</a>

Date: 12-Nov-2012
Time: 12:30pm PT
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 741 524 342
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=741524342
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-866-546-3377  (US)
Call-in number (Premiere): 1-719-234-7872  (US)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546
-3377&num2=1719-234-7872
Attendee access code: 982 762 9443
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From curtis.stevens at wdc.com  Thu Nov  8 14:29:46 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Nov 2012 22:29:46 +0000
Subject: SOPQI Letter Ballot Comment Resolution
Message-ID: <mailman.328.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211082_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211082_nameless-3832-9.txt">nameless-3832-9.txt</a>

Date: 26-Nov-2012
Time: 12:30pm PT
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 741 205 989
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=741205989
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-866-546-3377  (US)
Call-in number (Premiere): 1-719-234-7872  (US)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546
-3377&num2=1719-234-7872
Attendee access code: 982 762 9443
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From curtis.stevens at wdc.com  Thu Nov  8 14:30:03 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Nov 2012 22:30:03 +0000
Subject: SOPQI Letter Ballot Comment Resolution
Message-ID: <mailman.329.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211083_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211083_nameless-3832-12.txt">nameless-3832-12.txt</a>

Date: 19-Nov-2012
Time: 12:30pm PT
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 741 524 342
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=741524342
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-866-546-3377  (US)
Call-in number (Premiere): 1-719-234-7872  (US)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546
-3377&num2=1719-234-7872
Attendee access code: 982 762 9443
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From curtis.stevens at wdc.com  Thu Nov  8 14:31:37 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Nov 2012 22:31:37 +0000
Subject: SOPQI Letter Ballot Comment Resolution
Message-ID: <mailman.330.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211084_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211084_nameless-3832-15.txt">nameless-3832-15.txt</a>

Date: 3-DEC-2012
Time: 12:30pm PT
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 749 169 067
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=749169067
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-866-546-3377  (US)
Call-in number (Premiere): 1-719-234-7872  (US)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546
-3377&num2=1719-234-7872
Attendee access code: 982 762 9443
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From curtis.stevens at wdc.com  Thu Nov  8 14:33:57 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Nov 2012 22:33:57 +0000
Subject: SOPQI Letter Ballot Comment Resolution
Message-ID: <mailman.331.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211085_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211085_nameless-3832-18.txt">nameless-3832-18.txt</a>

Date: 17-DEC-2012
Time: 12:30pm PT
PQI Resolutions Only
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 743 492 670
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=743492670
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-866-546-3377  (US)
Call-in number (Premiere): 1-719-234-7872  (US)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546
-3377&num2=1719-234-7872
Attendee access code: 982 762 9443
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From curtis.stevens at wdc.com  Thu Nov  8 14:32:10 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Nov 2012 22:32:10 +0000
Subject: SOPQI Letter Ballot Comment Resolution
Message-ID: <mailman.332.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211086_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211086_nameless-3832-21.txt">nameless-3832-21.txt</a>

Date: 19-Nov-2012
Time: 12:30pm PT
PQI Review Only
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 741 524 342
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=741524342
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-866-546-3377  (US)
Call-in number (Premiere): 1-719-234-7872  (US)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546
-3377&num2=1719-234-7872
Attendee access code: 982 762 9443
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From curtis.stevens at wdc.com  Thu Nov  8 14:34:53 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Nov 2012 22:34:53 +0000
Subject: SOPQI Letter Ballot Comment Resolution
Message-ID: <mailman.333.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211087_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211087_nameless-3832-24.txt">nameless-3832-24.txt</a>

Date: 3-DEC-2012
Time: 12:30pm PT
SOP Review
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 749 169 067
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=749169067
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-866-546-3377  (US)
Call-in number (Premiere): 1-719-234-7872  (US)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546
-3377&num2=1719-234-7872
Attendee access code: 982 762 9443
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From curtis.stevens at wdc.com  Thu Nov  8 14:34:17 2012
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Nov 2012 22:34:17 +0000
Subject: SOPQI Letter Ballot Comment  Resolution
Message-ID: <mailman.334.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211088_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211088_nameless-3832-27.txt">nameless-3832-27.txt</a>

Date: 12-Nov-2012
Time: 12:30pm PT
SOP Resolutions
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 747 266 562
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://premconf.webex.com/premconf/j.php?J=747266562
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: This meeting does
not require a password.
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Teleconference information
-------------------------------------------------------
Call-in toll-free number (Premiere): 1-866-546-3377  (US)
Call-in number (Premiere): 1-719-234-7872  (US)
Show global numbers:
https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546
-3377&num2=1719-234-7872
Attendee access code: 982 762 9443
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From Dave.Landsman at sandisk.com  Fri Nov  9 08:48:04 2012
From: Dave.Landsman at sandisk.com (Dave Landsman)
Date: Fri, 9 Nov 2012 16:48:04 +0000
Subject: SAT-3 Meeting - Monday - December 10 - SanDisk
Message-ID: <mailman.335.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211090_f.htm">HTML-formatted message</a>

The SAT-3 meeting will be on Monday, December 10, at SanDisk, 601 McCarthy
Blvd, Milpitas, CA.  See meeting announcement
(http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-451r0.pdf) for full information.
Please RSVP so we have enough coffee and goodies.  Dave
Dave Landsman | Sr. Staff Engineer
Standardization and Industry Associations
SanDisk | m. 206.484.4782 | t. 206.275.4385
________________________________
PLEASE NOTE: The information contained in this electronic mail message is
intended only for the use of the designated recipient(s) named above. If the
reader of this message is not the intended recipient, you are hereby notified
that you have received this message in error and that any review,
dissemination, distribution, or copying of this message is strictly
prohibited. If you have received this communication in error, please notify
the sender by telephone or e-mail (as shown above) immediately and destroy
any and all copies of this message in your possession (whether hard copies or
electronically stored copies).


From lohmeyer at t10.org  Sat Nov 10 23:01:22 2012
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 11 Nov 2012 00:01:22 -0700
Subject: Recent T10 documents uploaded since 2012/11/04
Message-ID: <mailman.336.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC-3 LBP Log page example annex
(by: Frederick Knight)
T10/11-030r3   Uploaded: 2012/11/06   255896 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-030r3.pdf
SSC-4: Letter Ballot Comment Database
(by: David Peterson)
T10/11-478r7   Uploaded: 2012/11/07   3185410 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-478r7.pdf
T13 Liaison Report to T10
(by: Dan Colegrove)
T10/12-077r5   Uploaded: 2012/11/08   10371 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-077r5.pdf
SSC-4: Informational Exceptions Control mode page
(by: Curtis Ballard)
T10/12-245r4   Uploaded: 2012/11/07   124530 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-245r4.pdf
SBC-3: VERIFY SAME command
(by: Frederick Knight)
T10/12-246r4   Uploaded: 2012/11/06   237005 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-246r4.pdf
Logical Unit Groups (aka Conglomerates) in SAM-5 and SPC-5
(by: Ralph Weber)
T10/12-247r5   Uploaded: 2012/11/04   117754 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-247r5.pdf
SAT-3: VERIFY SAME Translation
(by: Frederick Knight)
T10/12-248r3   Uploaded: 2012/11/06   114961 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-248r3.pdf
SBC-3 Allow verify operations on unmapped LBAs
(by: Rob Elliott)
T10/12-282r4   Uploaded: 2012/11/09   347348 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-282r4.pdf
SBC-3 REASSIGN BLOCKS simplifications for logical block provisioning
(by: Rob Elliott)
T10/12-283r3   Uploaded: 2012/11/09   537358 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-283r3.pdf
SAS-3 open items list
(by: Alvin Cox)
T10/12-361r2   Uploaded: 2012/11/06   58259 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-361r2.pdf
SBC-3 GET LBA STATUS and related clarifications
(by: Rob Elliott)
T10/12-368r2   Uploaded: 2012/11/09   193373 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-368r2.pdf
Minutes SSC-4 September 12, 2012
(by: Kevin Butt)
T10/12-378r1   Uploaded: 2012/11/08   29767 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-378r1.pdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r3   Uploaded: 2012/11/05   2971392 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r3.fdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r3   Uploaded: 2012/11/05   6876159 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r3.pdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r4   Uploaded: 2012/11/07   7336850 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r4.pdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r4   Uploaded: 2012/11/07   471102 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r4.zip
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r5   Uploaded: 2012/11/08   7459196 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r5.pdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r5   Uploaded: 2012/11/08   486541 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r5.zip
SAS-3: End-to-end simulation status
(by: Mathieu Gagnon)
T10/12-381r1   Uploaded: 2012/11/06   589602 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-381r1.pdf
SES-3 : Door Lock Element Modifications
(by: Kevin Marks)
T10/12-384r1   Uploaded: 2012/11/06   28414 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-384r1.pdf
SPL-3 Add reporting of POWER DISABLE signal support
(by: Gerald Houlder)
T10/12-401r1   Uploaded: 2012/11/06   98059 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-401r1.pdf
SAT-3: Replace EPC tables with flowcharts
(by: Mark Overby)
T10/12-412r0   Uploaded: 2012/11/04   250675 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-412r0.pdf
SPL-2: Inside ZPSDS persistent = 0 is broken
(by: George Penokie)
T10/12-419r1   Uploaded: 2012/11/07   139893 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-419r1.pdf
SBC-3 Clearing pseudo unrecovered errors
(by: Rob Elliott)
T10/12-420r1   Uploaded: 2012/11/09   124410 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-420r1.pdf
SAT-3 Letter Ballot Comment Resolutions
(by: Mark Overby)
T10/12-422r0   Uploaded: 2012/11/04   5086698 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-422r0.pdf
SAT-3: Letter Ballot Comment Resolutions
(by: Mark Overby)
T10/12-422r1   Uploaded: 2012/11/06   5160524 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-422r1.pdf
Minutes of CAP Working Group - November 5-6, 2012
(by: Weber & Lohmeyer)
T10/12-430r0   Uploaded: 2012/11/07   76406 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-430r0.htm
Minutes of CAP Working Group - November 5-6, 2012
(by: Weber & Lohmeyer)
T10/12-430r0   Uploaded: 2012/11/07   177520 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-430r0.pdf
Minutes of SAS Protocol Working Group - November 7, 2012
(by: Weber & Lohmeyer)
T10/12-431r0   Uploaded: 2012/11/07   33920 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-431r0.htm
Minutes of SAS Protocol Working Group - November 7, 2012
(by: Weber & Lohmeyer)
T10/12-431r0   Uploaded: 2012/11/07   96505 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-431r0.pdf
Minutes of SOP PQI WG 2012-11-7 to 2012-11-08
(by: Rob Elliott)
T10/12-433r0   Uploaded: 2012/11/09   137808 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-433r0.pdf
SSC-4: Response to LB #IBM-36 (Append-only & BOP)
(by: Kevin Butt)
T10/12-439r1   Uploaded: 2012/11/08   46974 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-439r1.pdf
Minutes SSC-4 November 07, 2012
(by: Kevin Butt)
T10/12-440r0   Uploaded: 2012/11/08   23084 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-440r0.pdf
SAM-5: Who 'Owns' These LUNs?
(by: Ralph Weber)
T10/12-441r0   Uploaded: 2012/11/04   47607 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-441r0.pdf
SBC-4 - Storage Device Identification # Media (Medium) Type
(by: Calvin Chen)
T10/12-442r0   Uploaded: 2012/11/05   581667 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-442r0.pdf
Draft of T10- Storage Device Identification Proposal-r1
(by: Calvin Chen)
T10/12-442r1   Uploaded: 2012/11/07   581098 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-442r1.pdf
SAS-3 Preset +/-1.5 dB
(by: Harvey Newman)
T10/12-443r0   Uploaded: 2012/11/05   173360 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-443r0.pdf
SAS-3 addition of RJ for trained 12Gbps stressed receiver test
(by: Alvin Cox)
T10/12-444r0   Uploaded: 2012/11/06   202344 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-444r0.pdf
SAS-3 addition of RJ for trained 12Gbps stressed receiver test
(by: Alvin Cox)
T10/12-444r1   Uploaded: 2012/11/06   228957 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-444r1.pdf
SAS-3 Reference receiver peaking and reference transmitter
coefficient limits
(by: Mathieu Gagnon)
T10/12-445r0   Uploaded: 2012/11/06   82610 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-445r0.pdf
Agenda for T10 Meeting #113 January 10, 2013
(by: John Lohmeyer)
T10/12-446r0   Uploaded: 2012/11/08   13157 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-446r0.pdf
T10 Project Summary - November 2012
(by: John Lohmeyer)
T10/12-447r0   Uploaded: 2012/11/08   30153 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-447r0.pdf
Jeopardy Letter for January 2013 meeting
(by: John Lohmeyer)
T10/12-448r0   Uploaded: 2012/11/08   32615 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-448r0.pdf
SSC-4: Status Report - November 2012
(by: David Peterson)
T10/12-449r0   Uploaded: 2012/11/08   18660 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-449r0.pdf
STA - T10 Liaison Report November 8, 2012
(by: Marty Czekalski)
T10/12-450r0   Uploaded: 2012/11/08   113185 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-450r0.pdf
SAT-3 Meeting Announcement- December 2012
(by: Dave Landsman)
T10/12-451r0   Uploaded: 2012/11/08   343207 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-451r0.pdf
Working Drafts
--------------
SAS Protocol Layer - 3 (SPL-3)
(Editor: George Penokie)
 Rev: 00       Uploaded: 2012/11/08   9066633 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl3r00.pdf
(Report generated on 2012/11/11 at 00:01:22)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From alvin.cox at seagate.com  Mon Nov 12 08:29:57 2012
From: alvin.cox at seagate.com (Alvin Cox)
Date: Mon, 12 Nov 2012 10:29:57 -0600
Subject: SAS PHY teleconference schedule
Message-ID: <mailman.337.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211120_f.htm">HTML-formatted message</a>

Telecons are planned for November 15th, November 29th, December 13th,
December 20th, and January 3rd.
The Webex is set up for weekly, but the schedule is more bi-weekly as noted
above.
SAS PHY meeting logistics:
 Toll Free Dial in Number: (877)810-9442
International Access/Caller Paid Dial In Number: (636)651-3190
PARTICIPANT CODE: 3243413
Webex information:**
Topic: SAS-3
Date: Every Thursday, from Thursday, November 15, 2012 to Thursday, January
3, 2013
Time: 10:00 am, Central Standard Time (Chicago, GMT-06:00)
Meeting Number: 827 988 093
Meeting Password: sas12gbps
1. Go to
https://seagate.webex.com/seagate/j.php?ED=158650437&UID=0&PW=NODQzMjNhYTdm&R
T=MiM3
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: sas12gbps
4. Click "Join".
5. Follow the instructions that appear on your screen.
To view in other time zones or languages, please click the link:
https://seagate.webex.com/seagate/j.php?ED=158650437&UID=0&PW=NODQzMjNhYTdm&O
RT=MiM3
For assistance
1. Go to https://seagate.webex.com/seagate/mc
2. On the left navigation bar, click "Support".
To update this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://seagate.webex.com/seagate/j.php?ED=158650437&UID=0&ICS=UMI&LD=1&RD=2&
ST=1&SHA2=pEI2tL0j5oE58s9ytOQWHuV98SACdVZgiFnrG-CNDds=&RT=MiM3
WebEx will automatically setup Meeting Manager for Windows the first time
you join a meeting. To save time, you can setup prior to the meeting by
clicking this link:
https://seagate.webex.com/seagate/meetingcenter/mcsetup.php
-- 
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809
Office 405-392-3738
E-Mail	alvin.cox at seagate.com


From George.Penokie at lsi.com  Mon Nov 12 08:42:09 2012
From: George.Penokie at lsi.com (Penokie, George)
Date: Mon, 12 Nov 2012 09:42:09 -0700
Subject: Conference call for SCSI LU Conglomerates
Message-ID: <mailman.338.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211121_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211121_nameless-3748-3.txt">nameless-3748-3.txt</a>

When: Tuesday, December 18, 2012 2:30 PM-4:30 PM (GMT-06:00) Central Time (US
& Canada).
Note: The GMT offset above does not reflect daylight saving time adjustments.
*~*~*~*~*~*~*~*~*~*
George Penokie invites you to an online meeting using WebEx.
Meeting Number: 803 262 800
Meeting Password: scsiata
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to
https://lsi-corp.webex.com/lsi-corp/j.php?J=803262800&PW=NYjU3OGViYjc2
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: scsiata
4. Click "Join".
5. Follow the instructions that appear on your screen.
-------------------------------------------------------
Audio conference information
-------------------------------------------------------
Use the information below to connect:
Toll-free: +1 (866) 214-7945
Toll: +1 (702) 696-4029
Participant code: 5073289017
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From lohmeyer at t10.org  Tue Nov 13 09:33:55 2012
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 13 Nov 2012 10:33:55 -0700
Subject: Draft T10 plenary minutes posted
Message-ID: <mailman.339.1441607379.22528.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 Plenary meeting #112 (November 8, 2012) are
available at:
  http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-432r0.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 roweber at ieee.org  Tue Nov 13 15:15:01 2012
From: roweber at ieee.org (Ralph Weber)
Date: Tue, 13 Nov 2012 17:15:01 -0600
Subject: Version descriptors updated
Message-ID: <mailman.340.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
For the first time since the SPC-4 Letter Ballot, I have updated
the version descriptors on the T10 website.
http://www.t10.org/lists/2stds.htm
The biggest change was to switch from INCITS Project Numbers to
INCITS BSR Numbers for all active projects. Several new projects
and a couple of publications were also added.
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  Wed Nov 14 13:17:53 2012
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 14 Nov 2012 14:17:53 -0700
Subject: T10 Reflector clean up
Message-ID: <mailman.341.1441607379.22528.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 and are being removed:
  walter.gaspard at hp.com
  greg.tabor at maxim-ic.com
  Steven.Curtis at maxim-ic.com
  Jeremiah.Tussey at maxim-ic.com
  r.deglin at sisa.samsung.com
  j.osterlund at sisa.samsung.com
  andrew.dahlgaard at hds.com
  GGoodwin at plianttechnology.com
  Jeremiah.Tussey at maxim-ic.com
  Steven.Curtis at maxim-ic.com
  aeasi at cup.hp.com
  michael.banther at arkivum.com
These people may re-subscribe (hopefully, with a better address) by  using
the following URL:
  http://www.t10.org/t10r.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 roweber at ieee.org  Sat Nov 17 15:53:48 2012
From: roweber at ieee.org (Ralph Weber)
Date: Sat, 17 Nov 2012 17:53:48 -0600
Subject: Agenda item for 18 Dec Logical Unit Conglomerates call
Message-ID: <mailman.342.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Document 12-247r7 has been posted for consideration during the 18 
December conference call.
Document URL:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-247r7.pdf
Conference call announcement URL:
http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211121.htm
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 Nov 17 23:01:26 2012
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 18 Nov 2012 00:01:26 -0700
Subject: Recent T10 documents uploaded since 2012/11/11
Message-ID: <mailman.343.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC-3: Definitions for read, write, verify, and unmap operations
(by: Mark Evans)
T10/12-139r5   Uploaded: 2012/11/13   201306 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-139r5.pdf
SBC-3: Sanitize operation definition clarification and expansion>
(by: Mark Evans)
T10/12-220r5   Uploaded: 2012/11/13   34598 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-220r5.pdf
Logical Unit Groups (aka Conglomerates) in SAM-5 and SPC-5
(by: Ralph Weber)
T10/12-247r6   Uploaded: 2012/11/15   112303 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-247r6.pdf
Logical Unit Groups (aka Conglomerates) in SAM-5 and SPC-5
(by: Ralph Weber)
T10/12-247r7   Uploaded: 2012/11/17   113454 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-247r7.pdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r6   Uploaded: 2012/11/12   8024615 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r6.pdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r6   Uploaded: 2012/11/12   499243 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r6.zip
SAS-3: End-to-end simulation status
(by: Mathieu Gagnon)
T10/12-381r2   Uploaded: 2012/11/16   615644 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-381r2.pdf
SBC-3: Clarifications to POPULATE TOKEN and UNMAP length errors
(by: Frederick Knight)
T10/12-403r1   Uploaded: 2012/11/13   189241 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-403r1.pdf
SPC-4: Add Not Ready ASCs for Subsidiary Logical Units
(by: David Black, Murali Rajagopal)
T10/12-415r2   Uploaded: 2012/11/16   16963 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-415r2.pdf
SBC-3 Model Logical Unit operations as classes
(by: Rob Elliott)
T10/12-417r3   Uploaded: 2012/11/14   142643 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-417r3.pdf
SOP PQI Class diagrams for PQI domains
(by: Rob Elliott)
T10/12-426r1   Uploaded: 2012/11/12   165060 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-426r1.pdf
Minutes of T10 Plenary Meeting #112 - November 8, 2012
(by: Weber & Lohmeyer)
T10/12-432r0   Uploaded: 2012/11/13   149818 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-432r0.htm
Minutes of T10 Plenary Meeting #112 - November 8, 2012
(by: Weber & Lohmeyer)
T10/12-432r0   Uploaded: 2012/11/13   306297 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-432r0.pdf
Minutes of SAS PHY Working Group - November 6, 2012
(by: Alvin Cox, Bill Voorhees)
T10/12-437r0   Uploaded: 2012/11/12   58757 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-437r0.pdf
SPC REPORT LUNS Inventory Example from 12-124
(by: Ralph Weber)
T10/12-453r0   Uploaded: 2012/11/11   55572 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-453r0.pdf
SSC-4: Questions on the Verify behaviors of the new VBF and VTE bits
(by: Kevin Butt)
T10/12-455r0   Uploaded: 2012/11/14   16580 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-455r0.pdf
Meeting Announcement: T10 Week Jul 15-19, 2013 -- Colorado Springs, CO
(by: John Lohmeyer)
T10/12-456r0   Uploaded: 2012/11/15   20700 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-456r0.pdf
SOP/PQI: Making Some Checks During SGL Processing Optional
(by: Stephen Finch)
T10/12-457r0   Uploaded: 2012/11/15   62336 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-457r0.pdf
SOP Qualify request identifier with outbound queue identifier
(by: Rob Elliott)
T10/12-458r0   Uploaded: 2012/11/15   167950 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-458r0.pdf
SBC-3 LBP Log page example annex
(by: Frederick Knight)
T10/13-001r0   Uploaded: 2012/11/16   211357 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-001r0.pdf
Working Drafts
--------------
Serial Attached SCSI - 3 (SAS-3)
(Editor: Alvin Cox)
 Rev: 04       Uploaded: 2012/11/15   3178668 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sas3r04.pdf
Serial Attached SCSI - 3 (SAS-3)
(Editor: Alvin Cox)
 Rev: 04       Uploaded: 2012/11/15   3595391 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sas3r04.zip
SAS Protocol Layer - 3 (SPL-3)
(Editor: George Penokie)
 Rev: 01       Uploaded: 2012/11/12   9043214 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl3r01.pdf
SCSI Stream Commands - 4
(Editor: Dave Peterson)
 Rev: 02b      Uploaded: 2012/11/14   4383452 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=ssc4r02b.pdf
(Report generated on 2012/11/18 at 00:01:26)
*
* 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 Nov 24 23:01:29 2012
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 25 Nov 2012 00:01:29 -0700
Subject: Recent T10 documents uploaded since 2012/11/18
Message-ID: <mailman.344.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPL-3 Persistent Connection
(by: George Penokie)
T10/12-251r6   Uploaded: 2012/11/21   617222 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-251r6.pdf
SPL-3:Management ECM/Application Client connection close request
(by: George Penokie)
T10/12-380r3   Uploaded: 2012/11/21   558506 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-380r3.pdf
SOP PQI Class diagrams for PQI domains
(by: Rob Elliott)
T10/12-426r2   Uploaded: 2012/11/21   209860 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-426r2.pdf
SAM-5 - Add Data Transfer Terminated operation to Task Manager class
(by: George Penokie)
T10/13-003r0   Uploaded: 2012/11/20   72653 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-003r0.pdf
Working Drafts
--------------
SCSI Enclosure Services - 3 (SES-3)
(Editor: Fred Knight)
 Rev: 05       Uploaded: 2012/11/20   704751 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=ses3r05.pdf
(Report generated on 2012/11/25 at 00:01:29)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Rakesh.KN at jdsu.com  Mon Nov 26 23:15:26 2012
From: Rakesh.KN at jdsu.com (Rakesh KN)
Date: Tue, 27 Nov 2012 07:15:26 +0000
Subject: Question on Tx training in SAS protocol Layer: Requirement of
 HOLD TTIU after INIT bit goes low
Message-ID: <mailman.345.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211270_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211270_image001.jpg">image001.jpg</a>

Thanks for the clarification George.
Best Regards
Rakesh K N
Senior R&D Engineer
Storage Network Tools
Email:	  rakesh.kn at jdsu.com
[Description: cid:image001.jpg at 01CB8FE0.92C8F1C0]
You Know Us!
The world depends on our technology.
Our work touches everyone, every day.
Check out JDSU from a Different View.
http://www.jdsu.com
From: Penokie, George [mailto:George.Penokie at lsi.com]
Sent: Monday, November 26, 2012 11:27 PM
To: Rakesh KN
Cc: t10 at t10.org
Subject: RE: Question on Tx training in SAS protocol Layer: Requirement of
HOLD TTIU after INIT bit goes low
Rakesh,
Thanks for pointing this out. The text is correct as figure 103 has an error
in that the Set Coefficient 1 Request (Hold) should be Set Coefficient 1
Request.  This change was the result of a letter ballot comment. The
requirement to wait for a Hold was removed to prevent a possible hang that
could occur if a single Hold was followed by Increment or Decrement and that
single Hold was lost for some reason.
I will correct figure 103 in the next revision of SPL-3.
Figure 83 is only intended to as an example that shows normal behavior.
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at lsi.com
From: Rakesh KN [mailto:Rakesh.KN at jdsu.com]
Sent: Monday, November 26, 2012 12:08 AM
To: Penokie, George
Cc: t10 at t10.org
Subject: Question on Tx training in SAS protocol Layer: Requirement of HOLD
TTIU after INIT bit goes low
Hi George Penokie,
    Please can you clarify on the whether a hold TTIU is required after the
INIT bit goes low during TX training. In the figures in pg 271 and pg 197 of
the spec "SAS Protocol Layer - 3 (SPL-3)Revision 01 21 November 2012" it
shows HOLD TTIU requirement after INIT goes low . I am	wondering are these
just illustrations and not requirements. In the spec on page 271 the fig says
that transition to Transition PTT_SC1_0:Idle to PTT_SC1_1:Wait_Inc_Dec is by
Set Coefficient 1 Request message (HOLD) but in explanation on pg 272 this is
not mentioned. Please see the fig below for the details.
Thanks in advance
Best Regards
Rakesh
Senior R&D Engineer
Storage Network Tools
DID:	   (65) 6602 8506
Email:	  rakesh.kn at jdsu.com
[Description: cid:image001.jpg at 01CB8FE0.92C8F1C0]
You Know Us!
The world depends on our technology.
Our work touches everyone, every day.
Check out JDSU from a Different View.
http://www.jdsu.com


From gerry.houlder at seagate.com  Tue Nov 27 07:27:12 2012
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Tue, 27 Nov 2012 09:27:12 -0600
Subject: Behavior of TEST UNIT READY command in idle and standby power conditions
Message-ID: <mailman.346.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211271_f.htm">HTML-formatted message</a>

Some questions have come up about the behavior of TEST UNIT READY command
when the target is in an idle or standby power condition.
One opinion is that TUR should be treated as a command that can be
processed in idle and standby power conditions, so therefore should
complete with GOOD status.
Another opinion is that TUR should respond with CHECK CONDITION status with
sense bytes indicating the target is in a low power condition and the
target should not attempt  to change to a higher power condition. (Read or
write commands would trigger the target to change to active power
condition, so TUR action would be different). The advantage of this
behavior is that it could be used to poll for low power conditions in lieu
of using REQUEST SENSE command.
The existing description of TUR command in SPC-4 rev. 36e doesn't address
the expected behavior for this case, other than the table of "preferred TUR
responses" doesn't include any of the low power condition sense
combinations. However, folks can argue that there are a lot of other
combinations that are not included there but should be reported if the
conditions are present.
I would like to see responses on the reflector for the preferred behavior
of TUR when in a low power condition. If there is a convergence of opinion,
i would like to have that opinion reflected in description of the TEST UNIT
READY command to avoid having to readdress this issue in the future.


From mj at feral.com  Tue Nov 27 09:19:47 2012
From: mj at feral.com (Matthew Jacob)
Date: Tue, 27 Nov 2012 09:19:47 -0800
Subject: Behavior of TEST UNIT READY command in idle and standby power
 conditions
Message-ID: <mailman.347.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Matthew Jacob <mj at feral.com>
*
On 11/27/12 07:27, Gerry Houlder wrote:
> Some questions have come up about the behavior of TEST UNIT READY 
> command when the target is in an idle or standby power condition.
>
> One opinion is that TUR should be treated as a command that can be 
> processed in idle and standby power conditions, so therefore should 
> complete with GOOD status.
>
> Another opinion is that TUR should respond with CHECK CONDITION status 
> with sense bytes indicating the target is in a low power condition and 
> the target should not attempt  to change to a higher power condition. 
> (Read or write commands would trigger the target to change to active 
> power condition, so TUR action would be different). The advantage of 
> this behavior is that it could be used to poll for low power 
> conditions in lieu of using REQUEST SENSE command.
>
Why would this be any different than a TUR response for a spun down disk 
which responds with a check condition that asc that says in essence 
"need spinup"?
You know the unit is there and present because it responds to the TUR 
(with any status). You know that it isn't ready (for media access in the 
case of disk) because of the specific CHECK CONDITION response.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From p.lavarre at ieee.org  Tue Nov 27 10:12:53 2012
From: p.lavarre at ieee.org (Pat LaVarre)
Date: Tue, 27 Nov 2012 10:12:53 -0800
Subject: Behavior of TEST UNIT READY command in idle and standby power conditions
Message-ID: <mailman.348.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211273_f.htm">HTML-formatted message</a>

@ If there is a convergence of opinion, ...
...
Me, I've voted to ship both choices, in different contexts.
I shipped Test Unit Ready passing with Good status in low power, when I
could spin up fast enough to answer any Read within five seconds.
I shipped Test Unit Ready crashing via Check Condition status and throwing
Kcq's like x20402 Initializing Command Required or the rudely fuzzier x
20400 Cause Not Reportable, when I couldn't spin up fast enough to keep my
mass-market binary-code-only rarely-updated hosts from crashing in response
to my Target's automagic choice to reduce power and wear.
...
Changing a Target to signal low power by failing Test Unit Ready would
profitlessly bring all the host code crawling out of the woodwork that
doesn't expect that signal and also doesn't need to know about low power.
Changing a Host to poll with Request Sense would profitlessly crash all the
targets that don't expect that poll and don't report low power.
I'd hope that by now we've included plain simple reliable plug-n-pray
signals in the core leading x24 (36) bytes of the main Page of Inquiry to
tell the Host which kind of polling to try or neither.
...
Polling doesn't reduce power consumption.
Polling with Test Unit Ready can cost more power when the device returns a
Check Condition and then the host adds a Request Sense - so we spend all
the cost of Request Sense anyhow plus the cost of Test Unit Ready.
Polling with Test Unit Ready has been more popular = is now more polite -
than polling with Request Sense, which has been more often tested only
immediately after a Check Condition as part of clearing the Contingent
Allegiance. In my circles we spoke of, and sneered at, Unsolicited Request
Sense as being a Request Sense after status other than Check Condition.
Polling with Test Unit Ready is simpler = more reliable = more polite:
normally just Cdb and Good Status, abnormally Cdb and Check Condition
Status, never any Data to negotiate.
...
On Tue, Nov 27, 2012 at 9:19 AM, Matthew Jacob <mj at feral.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Matthew Jacob <mj at feral.com>
> *
>
> On 11/27/12 07:27, Gerry Houlder wrote:
>
>> Some questions have come up about the behavior of TEST UNIT READY command
>> when the target is in an idle or standby power condition.
>>
>> One opinion is that TUR should be treated as a command that can be
>> processed in idle and standby power conditions, so therefore should
>> complete with GOOD status.
>>
>> Another opinion is that TUR should respond with CHECK CONDITION status
>> with sense bytes indicating the target is in a low power condition and the
>> target should not attempt  to change to a higher power condition. (Read or
>> write commands would trigger the target to change to active power
>> condition, so TUR action would be different). The advantage of this
>> behavior is that it could be used to poll for low power conditions in lieu
>> of using REQUEST SENSE command.
>>
>>  Why would this be any different than a TUR response for a spun down disk
> which responds with a check condition that asc that says in essence "need
> spinup"?
>
> You know the unit is there and present because it responds to the TUR
> (with any status). You know that it isn't ready (for media access in the
> case of disk) because of the specific CHECK CONDITION response.
> *
> * 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  Tue Nov 27 12:14:13 2012
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Tue, 27 Nov 2012 14:14:13 -0600
Subject: Can we obsolete the Read Continuous bit?
Message-ID: <mailman.349.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211274_f.htm">HTML-formatted message</a>

I have the impression that the READ CONTINUOUS bit, in the READ WRITE
RECOVERY mode page, is not used by anyone.  I think it boils down to
everyone wanting data that can be trusted, even in video applications. Does
anyone have an application that justifies keeping this feature?


From Kevin_Marks at Dell.com  Tue Nov 27 13:40:02 2012
From: Kevin_Marks at Dell.com (Kevin_Marks at Dell.com)
Date: Tue, 27 Nov 2012 15:40:02 -0600
Subject: Behavior of TEST UNIT READY command in idle and standby power
 conditions
Message-ID: <mailman.350.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211275_f.htm">HTML-formatted message</a>

Not sure I agree Gerry.
The description in the TUR command says "If the logical unit is able to
accept an appropriate medium-access command without
returning CHECK CONDITION status, this command shall return a GOOD status. If
the logical unit is unable to become operational or is in a state such that
an application client action (e.g., START UNIT command) is required to make
the logical unit ready, the command shall be terminated with CHECK CONDITION
status, with the sense key set to NOT READY."
The only defined states where this is not the case is Stopped state or any
_wait state coming from stopped (and that was a legacy behavior).
It's all in the state machines.
Kevin
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Tuesday, November 27, 2012 9:27 AM
To: T10 Reflector
Subject: Behavior of TEST UNIT READY command in idle and standby power
conditions
Some questions have come up about the behavior of TEST UNIT READY command
when the target is in an idle or standby power condition.
One opinion is that TUR should be treated as a command that can be processed
in idle and standby power conditions, so therefore should complete with GOOD
status.
Another opinion is that TUR should respond with CHECK CONDITION status with
sense bytes indicating the target is in a low power condition and the target
should not attempt  to change to a higher power condition. (Read or write
commands would trigger the target to change to active power condition, so TUR
action would be different). The advantage of this behavior is that it could
be used to poll for low power conditions in lieu of using REQUEST SENSE
command.
The existing description of TUR command in SPC-4 rev. 36e doesn't address the
expected behavior for this case, other than the table of "preferred TUR
responses" doesn't include any of the low power condition sense combinations.
However, folks can argue that there are a lot of other combinations that are
not included there but should be reported if the conditions are present.
I would like to see responses on the reflector for the preferred behavior of
TUR when in a low power condition. If there is a convergence of opinion, i
would like to have that opinion reflected in description of the TEST UNIT
READY command to avoid having to readdress this issue in the future.


From Paul.Suhler at quantum.com  Tue Nov 27 13:44:54 2012
From: Paul.Suhler at quantum.com (Paul Suhler)
Date: Tue, 27 Nov 2012 21:44:54 +0000
Subject: Can we obsolete the Read Continuous bit?
Message-ID: <mailman.351.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211276_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211276_image001.gif">image001.gif</a>

Quantum has no objection to obsoleting this bit.
Paul
_____________________________________________________________________________
________________________
Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com
[be-certain_lockup.gif]<http://www.quantum.com/&gt;
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Tuesday, November 27, 2012 12:14 PM
To: T10 Reflector
Subject: Can we obsolete the Read Continuous bit?
I have the impression that the READ CONTINUOUS bit, in the READ WRITE
RECOVERY mode page, is not used by anyone.  I think it boils down to everyone
wanting data that can be trusted, even in video applications. Does anyone
have an application that justifies keeping this feature?


From gerry.houlder at seagate.com  Tue Nov 27 14:36:47 2012
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Tue, 27 Nov 2012 16:36:47 -0600
Subject: Behavior of TEST UNIT READY command in idle and standby power conditions
Message-ID: <mailman.352.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211277_f.htm">HTML-formatted message</a>

Thanks for the replies so far, but I am having a hard time interpreting
them as favoring either:
(1) TUR should complete with GOOD status (act as if the command can be
processed in idle and standby condition), or
(2) TUR should complete with CHECK CONDITION status and some flavor of NOT
READY (depending on mode page settings).
Please state preferred behavior.
On Tue, Nov 27, 2012 at 3:40 PM, <Kevin_Marks at dell.com> wrote:
> Not sure I agree Gerry.  ****
>
> ** **
>
> The description in the TUR command says ?If the logical unit is able to
> accept an appropriate medium-access command without****
>
> returning CHECK CONDITION status, this command shall return a GOOD status.
> If the logical unit is unable to become operational or is in a state such
> that an application client action (e.g., START UNIT command) is required to
> make the logical unit ready, the command shall be terminated with CHECK
> CONDITION status, with the sense key set to NOT READY.? ****
>
> ** **
>
> The only defined states where this is not the case is Stopped state or any
> _wait state coming from stopped (and that was a legacy behavior). ****
>
> ** **
>
> It?s all in the state machines.****
>
> ** **
>
> Kevin****
>
> ** **
>
> ** **
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Gerry
> Houlder
> *Sent:* Tuesday, November 27, 2012 9:27 AM
> *To:* T10 Reflector
> *Subject:* Behavior of TEST UNIT READY command in idle and standby power
> conditions****
>
> ** **
>
> Some questions have come up about the behavior of TEST UNIT READY command
> when the target is in an idle or standby power condition.****
>
> ** **
>
> One opinion is that TUR should be treated as a command that can be
> processed in idle and standby power conditions, so therefore should
> complete with GOOD status.****
>
> ** **
>
> Another opinion is that TUR should respond with CHECK CONDITION status
> with sense bytes indicating the target is in a low power condition and the
> target should not attempt  to change to a higher power condition. (Read or
> write commands would trigger the target to change to active power
> condition, so TUR action would be different). The advantage of this
> behavior is that it could be used to poll for low power conditions in lieu
> of using REQUEST SENSE command.****
>
> ** **
>
> The existing description of TUR command in SPC-4 rev. 36e doesn't address
> the expected behavior for this case, other than the table of "preferred TUR
> responses" doesn't include any of the low power condition sense
> combinations. However, folks can argue that there are a lot of other
> combinations that are not included there but should be reported if the
> conditions are present.****
>
> ** **
>
> I would like to see responses on the reflector for the preferred behavior
> of TUR when in a low power condition. If there is a convergence of opinion,
> i would like to have that opinion reflected in description of the TEST UNIT
> READY command to avoid having to readdress this issue in the future.****
>
> ** **
>


From kdbutt at us.ibm.com  Tue Nov 27 14:56:05 2012
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 27 Nov 2012 15:56:05 -0700
Subject: XCopy and failure status
Message-ID: <mailman.353.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211278_f.htm">HTML-formatted message</a>

When performing an extended copy and a failure occurs how does one 
determine which device, the source CSCD or the destination CSCD, generated 
the sense data related to the failure? 
I can see how to discover which operation caused the failure, but I would 
think the Parameter data for the RECEIVE COPY FAILURE DETAILS(LID1)command 
should contain a pointer to the CSCD which generated the sense data.  The 
same for the Parameter data for the RECEIVE COPY STATUS(LIDx) commands.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From mj at feral.com  Tue Nov 27 15:06:43 2012
From: mj at feral.com (Matthew Jacob)
Date: Tue, 27 Nov 2012 15:06:43 -0800
Subject: Behavior of TEST UNIT READY command in idle and standby power
 conditions
Message-ID: <mailman.354.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Matthew Jacob <mj at feral.com>
*
On 11/27/12 14:36, Gerry Houlder wrote:
> Thanks for the replies so far, but I am having a hard time 
> interpreting them as favoring either:
> (1) TUR should complete with GOOD status (act as if the command can be 
> processed in idle and standby condition), or
> (2) TUR should complete with CHECK CONDITION status and some flavor of 
> NOT READY (depending on mode page settings).
>
#2
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Kevin_Marks at Dell.com  Tue Nov 27 16:03:14 2012
From: Kevin_Marks at Dell.com (Kevin_Marks at Dell.com)
Date: Tue, 27 Nov 2012 18:03:14 -0600
Subject: Behavior of TEST UNIT READY command in idle and standby power
 conditions
Message-ID: <mailman.355.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r121127a_f.htm">HTML-formatted message</a>

#1, the LU is ready and can process commands in idle and standby and
transition to active if needed so what would u want to CC that?
If u choose #2 then u wiil be changing years of legacy behavior.
Kevin
Send from mobile device, excuse typos
-----Original Message-----
From: Matthew Jacob [mj at feral.com]
Sent: Tuesday, November 27, 2012 05:11 PM Central Standard Time
To: Gerry Houlder
Cc: T10 Reflector
Subject: Re: Behavior of TEST UNIT READY command in idle and standby power
conditions
* From the T10 Reflector (t10 at t10.org), posted by:
* Matthew Jacob <mj at feral.com>
*
On 11/27/12 14:36, Gerry Houlder wrote:
> Thanks for the replies so far, but I am having a hard time
> interpreting them as favoring either:
> (1) TUR should complete with GOOD status (act as if the command can be
> processed in idle and standby condition), or
> (2) TUR should complete with CHECK CONDITION status and some flavor of
> NOT READY (depending on mode page settings).
>
#2
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From p.lavarre at ieee.org  Tue Nov 27 16:26:32 2012
From: p.lavarre at ieee.org (Pat LaVarre)
Date: Tue, 27 Nov 2012 16:26:32 -0800
Subject: Behavior of TEST UNIT READY command in idle and standby power conditions
Message-ID: <mailman.356.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r121127b_f.htm">HTML-formatted message</a>

Of course I trust you all to ask me to sign out if I'm tangent'ing
un-entertainingly ...
...
Q: How could we encourage opinion to converge on such a question?
This Option for Check Condition/ Not Ready from Tur is, by its apparent
crowd-sourced design, an escape from simpler models, a way of allowing the
Target to fall into a state where it needs a Start Unit signal from the
host. With that option left open, Scsi is less simple and more flexible.
Thus Scsi is Scsi, not Ata. Targets that don't need that complexifying
option interoperate more broadly, but naive Hosts then fall unknowing into
supporting only those simpler Targets.
Can we gather votes around simplifying Scsi? Either radically to exclude
the Targets weirdly slow to return from Low Power, or inclusively to burden
even the more common and otherwise simpler quick-to-return targets with the
Low Power Check Condition? Or should we leave Scsi as conflicted with
itself as it always has been here?
...
Like Test Unit Ready has always been intrinsically paradoxical with itself.
I mean, just suppose the Target transitions to Low Power in the narrow time
window before the last Test Unit Ready or Request Sense Poll and the
arrival of a Read Cdb. Well then the Read must handle that condition. So
tell me again what the point of the Poll was? It's just to spend power to
help pretend that the host can handle spontaneous Target transitions to Low
Power, right?
The simplest kind of Scsi, the most power efficient, would forbid the host
poll on these inescapably logical grounds. Q: Poll with Test Unit Ready? A:
No. Q: Poll with Request Sense? A: No. Q: Cope with slow Target? A: Yes.
Like go exercise the discovery features, new in this last decade or two,
that help the host guess how unresponsive a Target might acceptably be, in
seconds elapsed.


From keiji_katata at post.pioneer.co.jp  Tue Nov 27 23:44:11 2012
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Wed, 28 Nov 2012 16:44:11 +0900
Subject: Can we obsolete the Read Continuous bit?
Message-ID: <mailman.357.1441607379.22528.t10@sandbox.t10.org>

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211280_pic04664.gif">pic04664.gif</a>

Hello Paul and Gerry,
The MMC devices use Streaming bit in Read12 command instead of Read
Continuous
bit in the mode page.
There is no problem to obsolete the bit.
Best regards,
Keiji Katata
PIONEER CORP.
Paul Suhler <Paul.Suhler at quantum.com>@t10.org on 2012/11/28 06:44:54
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B: T10 Reflector <t10 at t10.org>
cc:    (bcc: Keiji Katata/Pioneer)
$B7oL>(B: RE: Can we obsolete the Read Continuous bit?
Quantum has no objection to obsoleting this bit.
Paul
_____________________________________________________________________________
________________________
Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com
(Embedded image moved to file: pic04664.gif)be-certain_lockup.gif
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Tuesday, November 27, 2012 12:14 PM
To: T10 Reflector
Subject: Can we obsolete the Read Continuous bit?
I have the impression that the READ CONTINUOUS bit, in the READ WRITE
RECOVERY
mode page, is not used by anyone.  I think it boils down to everyone wanting
data that can be trusted, even in video applications. Does anyone have an
application that justifies keeping this feature?


From lohmeyer at t10.org  Wed Nov 28 01:00:00 2012
From: lohmeyer at t10.org (T10 List Manager)
Date: Wed, 28 Nov 2012 02:00:00 -0700
Subject: T10 Reflector Monthly Reminder
Message-ID: <mailman.358.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 List Manager <lohmeyer at t10.org>
*
This is an automatic monthly posting to the T10 Reflector.  If you
receive this message, it means that you are subscribed to the T10
Reflector email list.
The T10 Reflector is provided by the SCSI Trade Association and
maintained by LSI Corp. This reflector exists to discuss INCITS
T10 Technical Committee issues and to disseminate T10-related
information (minutes, meeting notices, etc.).
---------------------------------------------------------------------------
You do not need to be an INCITS T10 Technical Committee member to
use this reflector, however you must agree to:
 * read the INCITS Patent Policy and the INCITS Antitrust Guidelines
 * acknowledge that the activities of the T10 Technical Committee are
   governed by the INCITS policies and procedures as specified in the
   reference documents RD-1 and RD-2
 * acknowledge that draft documents may change at any time, without notice.
The INCITS Patent Policy, the INCITS Antitrust Guidelines, the RD-1, and
the RD-2 are all available on the www.incits.org web site.
If you do not agree to the above conditions, then you must unsubscribe
to this reflector.
---------------------------------------------------------------------------
T10 Reflector is not intended to carry commercial traffic. People who post
advertisements, job offers, etc. will be removed from the reflector.
Please visit http://www.t10.org/t10r.htm for instructions on subscribing,
unsubscribing, or searching the T10 Reflector archives.
*
* 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  Wed Nov 28 04:30:55 2012
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Wed, 28 Nov 2012 12:30:55 +0000
Subject: Behavior of TEST UNIT READY command in idle and standby power
 conditions
Message-ID: <mailman.359.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211282_f.htm">HTML-formatted message</a>

SPC and SBC already say that if the command is able to be processed, then
process it.
If the device went to idle, and it gets a READ, and the device is able to
process the READ, then do it.  NO CHECK CONDITION.
Therefore, if the device gets a TUR and the device is able to process a READ
(no matter what power condition it is in), then the status is GOOD.  There is
no CHECK CONDITION on that TUR.  AND, as was pointed out, it is still
possible that the device will change state in between the TUR and the READ,
so the TUR could still return GOOD and the READ return a CHECK CONDITION.
If the device is NOT able to process a READ, then when the TUR comes in, the
device returns CHECK CONDITION - NOT READY - INITIALIZING COMMAND REQUIRED. 
The host sends START UNIT.  When the START UNIT completes the host sends the
READ (it might also resend the TUR before sending the READ).  If the device
needs time to get ready, it takes that time during the processing of the
START UNIT command.
Not complex - just 2 cases.  GOOD or INITIALIZING COMMAND REQUIRED.
		Fred Knight
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pat LaVarre
Sent: Tuesday, November 27, 2012 7:27 PM
To: Matthew Jacob
Cc: Gerry Houlder; T10 Reflector
Subject: Re: Behavior of TEST UNIT READY command in idle and standby power
conditions
Of course I trust you all to ask me to sign out if I'm tangent'ing
un-entertainingly ...
...
Q: How could we encourage opinion to converge on such a question?
This Option for Check Condition/ Not Ready from Tur is, by its apparent
crowd-sourced design, an escape from simpler models, a way of allowing the
Target to fall into a state where it needs a Start Unit signal from the host.
With that option left open, Scsi is less simple and more flexible. Thus Scsi
is Scsi, not Ata. Targets that don't need that complexifying option
interoperate more broadly, but naive Hosts then fall unknowing into
supporting only those simpler Targets.
Can we gather votes around simplifying Scsi? Either radically to exclude the
Targets weirdly slow to return from Low Power, or inclusively to burden even
the more common and otherwise simpler quick-to-return targets with the Low
Power Check Condition? Or should we leave Scsi as conflicted with itself as
it always has been here?
...
Like Test Unit Ready has always been intrinsically paradoxical with itself. I
mean, just suppose the Target transitions to Low Power in the narrow time
window before the last Test Unit Ready or Request Sense Poll and the arrival
of a Read Cdb. Well then the Read must handle that condition. So tell me
again what the point of the Poll was? It's just to spend power to help
pretend that the host can handle spontaneous Target transitions to Low Power,
right?
The simplest kind of Scsi, the most power efficient, would forbid the host
poll on these inescapably logical grounds. Q: Poll with Test Unit Ready? A:
No. Q: Poll with Request Sense? A: No. Q: Cope with slow Target? A: Yes. Like
go exercise the discovery features, new in this last decade or two, that help
the host guess how unresponsive a Target might acceptably be, in seconds
elapsed.


From Frederick.Knight at netapp.com  Wed Nov 28 04:30:57 2012
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Wed, 28 Nov 2012 12:30:57 +0000
Subject: XCopy and failure status
Message-ID: <mailman.360.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211283_f.htm">HTML-formatted message</a>

See (SPC4r36e, page 263):
5.17.7.4 EXTENDED COPY command errors detected during processing of segment
descriptors
<...>
d) if the exception condition is reported by the copy source, then:
<...>
e) if the exception condition is reported by the copy destination, then:
There are pointers setup either in the first/second byte of the
COMMAND-SPECIFIC INFORMATION field (first byte = source device, second byte =
destination device); or the forwarded additional sense data descriptor is
used (depending on whether you're returning fixed or descriptor format sense
data.
		Fred
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
Sent: Tuesday, November 27, 2012 5:56 PM
To: T10 Reflector
Subject: XCopy and failure status
When performing an extended copy and a failure occurs how does one determine
which device, the source CSCD or the destination CSCD, generated the sense
data related to the failure?
I can see how to discover which operation caused the failure, but I would
think the Parameter data for the RECEIVE COPY FAILURE DETAILS(LID1)command
should contain a pointer to the CSCD which generated the sense data.  The
same for the Parameter data for the RECEIVE COPY STATUS(LIDx) commands.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 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 mj at feral.com  Wed Nov 28 06:52:25 2012
From: mj at feral.com (Matthew Jacob)
Date: Wed, 28 Nov 2012 06:52:25 -0800
Subject: Behavior of TEST UNIT READY command in idle and standby power
 conditions
Message-ID: <mailman.361.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211284_f.htm">HTML-formatted message</a>

On 11/28/2012 4:30 AM, Knight, Frederick wrote:
>
> SPC and SBC already say that if the command is able to be processed, 
> then process it.
>
> If the device went to idle, and it gets a READ, and the device is able 
> to process the READ, then do it.NO CHECK CONDITION.
>
> Therefore, if the device gets a TUR and the device is able to process 
> a READ (no matter what power condition it is in), then the status is 
> GOOD.There is no CHECK CONDITION on that TUR.AND, as was pointed out, 
> it is still possible that the device will change state in between the 
> TUR and the READ, so the TUR could still return GOOD and the READ 
> return a CHECK CONDITION.
>
> If the device is NOT able to process a READ, then when the TUR comes 
> in, the device returns CHECK CONDITION -- NOT READY -- INITIALIZING 
> COMMAND REQUIRED.The host sends START UNIT.When the START UNIT 
> completes the host sends the READ (it might also resend the TUR before 
> sending the READ).If the device needs time to get ready, it takes that 
> time during the processing of the START UNIT command.
>
> Not complex -- just 2 cases.GOOD or INITIALIZING COMMAND REQUIRED.
>
>
Very well put. That's what I was trying to convey.


From gerry.houlder at seagate.com  Wed Nov 28 07:09:51 2012
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Wed, 28 Nov 2012 09:09:51 -0600
Subject: Behavior of TEST UNIT READY command in idle and standby power conditions
Message-ID: <mailman.362.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211285_f.htm">HTML-formatted message</a>

Since "initializing command required" is only used for Stopped condition,
it sounds like you want TUR to report GOOD status from idle and standby
conditions. Am i interpreting you correctly?
On Wed, Nov 28, 2012 at 6:30 AM, Knight, Frederick <
Frederick.Knight at netapp.com> wrote:
>  SPC and SBC already say that if the command is able to be processed,
thenprocess it.
> ****
>
> ** **
>
> If the device went to idle, and it gets a READ, and the device is able to
> process the READ, then do it.  NO CHECK CONDITION.****
>
> ** **
>
> Therefore, if the device gets a TUR and the device is able to process a
> READ (no matter what power condition it is in), then the status is GOOD. 
There
> is no CHECK CONDITION on that TUR.  AND, as was pointed out, it is still
> possible that the device will change state in between the TUR and the READ,
> so the TUR could still return GOOD and the READ return a CHECK CONDITION.*
> ***
>
> ** **
>
> If the device is NOT able to process a READ, then when the TUR comes in,
> the device returns CHECK CONDITION ? NOT READY ? INITIALIZING COMMAND
> REQUIRED.  The host sends START UNIT.  When the START UNIT completes the
> host sends the READ (it might also resend the TUR before sending the READ).
> If the device needs time to get ready, it takes that time during the
> processing of the START UNIT command.****
>
> ** **
>
> Not complex ? just 2 cases.  GOOD or INITIALIZING COMMAND REQUIRED.****
>
> ** **
>
>		  Fred Knight****
>
> ** **
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Pat
> LaVarre
> *Sent:* Tuesday, November 27, 2012 7:27 PM
> *To:* Matthew Jacob
> *Cc:* Gerry Houlder; T10 Reflector
> *Subject:* Re: Behavior of TEST UNIT READY command in idle and standby
> power conditions****
>
> ** **
>
> Of course I trust you all to ask me to sign out if I'm tangent'ing
> un-entertainingly ...****
>
> ** **
>
> ...****
>
> ** **
>
> Q: How could we encourage opinion to converge on such a question?****
>
> ** **
>
> This Option for Check Condition/ Not Ready from Tur is, by its apparent
> crowd-sourced design, an escape from simpler models, a way of allowing the
> Target to fall into a state where it needs a Start Unit signal from the
> host. With that option left open, Scsi is less simple and more flexible.
> Thus Scsi is Scsi, not Ata. Targets that don't need that complexifying
> option interoperate more broadly, but naive Hosts then fall unknowing into
> supporting only those simpler Targets.****
>
> ** **
>
> Can we gather votes around simplifying Scsi? Either radically to exclude
> the Targets weirdly slow to return from Low Power, or inclusively to burden
> even the more common and otherwise simpler quick-to-return targets with the
> Low Power Check Condition? Or should we leave Scsi as conflicted with
> itself as it always has been here?****
>
> ** **
>
> ...****
>
> ** **
>
> Like Test Unit Ready has always been intrinsically paradoxical with
> itself. I mean, just suppose the Target transitions to Low Power in the
> narrow time window before the last Test Unit Ready or Request Sense Poll
> and the arrival of a Read Cdb. Well then the Read must handle that
> condition. So tell me again what the point of the Poll was? It's just to
> spend power to help pretend that the host can handle spontaneous Target
> transitions to Low Power, right?****
>
> ** **
>
> The simplest kind of Scsi, the most power efficient, would forbid the host
> poll on these inescapably logical grounds. Q: Poll with Test Unit Ready? A:
> No. Q: Poll with Request Sense? A: No. Q: Cope with slow Target? A: Yes.
> Like go exercise the discovery features, new in this last decade or two,
> that help the host guess how unresponsive a Target might acceptably be, in
> seconds elapsed.****
>


From Mark_Hollinger at Dell.com  Wed Nov 28 07:27:48 2012
From: Mark_Hollinger at Dell.com (Mark_Hollinger at Dell.com)
Date: Wed, 28 Nov 2012 15:27:48 +0000
Subject: Behavior of TEST UNIT READY command in idle and standby power
 conditions
Message-ID: <mailman.363.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <Mark_Hollinger at Dell.com>
*
> I mean, just suppose the Target transitions to Low Power in the narrow
> time window before the last Test Unit Ready or Request Sense Poll and
> the arrival of a Read Cdb. Well then the Read must handle that condition.
Ah, but if the transition into low-power state is based on idle time, then
the TUR will reset the timer -- or at least extend the time slightly.  A
sophisticated target might go to medium-power state after 5 minutes with no
actual I/O activity, and then low-power state after 30 minutes with no
activity at all.
> The simplest kind of Scsi, the most power efficient, would forbid the
> host poll on these inescapably logical grounds.
Actually, there is a logical escape if you consider the power efficiency of
the system as a whole.	There are many occasions when the host may want to
have a look around -- survey the landscape of attached devices without
necessarily doing any I/O.  For example, at OS boot time, or upon opening a
dialog box to select an input file, well-designed software will build a list
of drives using whatever information is immediately available.	You don't
want to spin up all the drives (introducing a 5 second delay and consuming
power), but if a LU happens to be ready, you might check the disk label or
read the top-level directory.
Power-conscious background tasks such as an indexing process or a virus scan
might also want to limit their I/O activity to SCSI devices that are already
spun up.  Polling improves efficiency if used to determine whether or not to
initiate I/O to a particular device, and it's important for a target to
return descriptive information when polled.
      - Mark Hollinger
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From alvin.cox at seagate.com  Wed Nov 28 11:13:59 2012
From: alvin.cox at seagate.com (Alvin Cox)
Date: Wed, 28 Nov 2012 13:13:59 -0600
Subject: Reminder: SAS PHY teleconference, November 29, 2012, 10:00 am CST
Message-ID: <mailman.364.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211287_f.htm">HTML-formatted message</a>

Agenda:
SAS-3 addition of POWER DISABLE
(12-363r5<http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-363r5.pdf&gt;)
[Cox]
(Updated electrical table on the last page.)
Connector related
Electrical
Toll Free Dial in Number: (877)810-9442
International Access/Caller Paid Dial In Number: (636)651-3190
PARTICIPANT CODE: 3243413
Webex information:**
Topic: SAS-3
Date: Every Thursday, from Thursday, November 15, 2012 to Thursday, January
3, 2013
Time: 10:00 am, Central Standard Time (Chicago, GMT-06:00)
Meeting Number: 827 988 093
Meeting Password: sas12gbps
1. Go to
https://seagate.webex.com/seagate/j.php?ED=158650437&UID=0&PW=NODQzMjNhYTdm&R
T=MiM3
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: sas12gbps
4. Click "Join".
5. Follow the instructions that appear on your screen.
To view in other time zones or languages, please click the link:
https://seagate.webex.com/seagate/j.php?ED=158650437&UID=0&PW=NODQzMjNhYTdm&O
RT=MiM3
For assistance
1. Go to https://seagate.webex.com/seagate/mc
2. On the left navigation bar, click "Support".
To update this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://seagate.webex.com/seagate/j.php?ED=158650437&UID=0&ICS=UMI&LD=1&RD=2&
ST=1&SHA2=pEI2tL0j5oE58s9ytOQWHuV98SACdVZgiFnrG-CNDds=&RT=MiM3
WebEx will automatically setup Meeting Manager for Windows the first time
you join a meeting. To save time, you can setup prior to the meeting by
clicking this link:
https://seagate.webex.com/seagate/meetingcenter/mcsetup.php


From Frederick.Knight at netapp.com  Thu Nov 29 06:41:50 2012
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Thu, 29 Nov 2012 14:41:50 +0000
Subject: Behavior of TEST UNIT READY command in idle and standby power
 conditions
Message-ID: <mailman.365.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211290_f.htm">HTML-formatted message</a>

No, not quite.	You're jumping to conclusions.
I'm suggesting that you forget about your internal state for just a minute
and focus on the visible behavior instead.  "INITIALIZING COMMAND REQUIRED"
is not necessarily only for when you are actually in the stopped condition
(remember, these are models).  There may be times that you want the initiator
to think you are in the stopped condition (even if you are not).  Yes, I
know, engineering sacrilege.  But, SCSI has always been more about the
visible behavior than actual verifiable internal state.
If you can process a READ command without error, then you are not in the
stopped condition (you return GOOD status).
If you cannot process a READ command and you need more time to be able to get
to the point where you are able to process the READ command, then what do you
do to get that time?  You have lots of choices (some of which work better in
some circumstances than others).  One choice to get more time is to get the
initiator to send a START UNIT command (because initiators know that spin-up
may take more time).  So, you tell them you are in the stopped condition to
trigger the action you need (you tell the host INITIALIZING COMMAND
REQUIRED).
I guess, what I'm saying, is that the answer isn't a simple black or white
(always GOOD, or always CHECK CONDITION).  Sometimes, you have to evaluate
your internal situation and make a decision as to which response is
appropriate for that situation.
		Fred
From: Gerry Houlder [mailto:gerry.houlder at seagate.com]
Sent: Wednesday, November 28, 2012 10:10 AM
To: Knight, Frederick
Cc: Pat LaVarre; Matthew Jacob; T10 Reflector
Subject: Re: Behavior of TEST UNIT READY command in idle and standby power
conditions
Since "initializing command required" is only used for Stopped condition, it
sounds like you want TUR to report GOOD status from idle and standby
conditions. Am i interpreting you correctly?
On Wed, Nov 28, 2012 at 6:30 AM, Knight, Frederick
<Frederick.Knight at netapp.com> wrote:
SPC and SBC already say that if the command is able to be processed, then
process it.
If the device went to idle, and it gets a READ, and the device is able to
process the READ, then do it.  NO CHECK CONDITION.
Therefore, if the device gets a TUR and the device is able to process a READ
(no matter what power condition it is in), then the status is GOOD.  There is
no CHECK CONDITION on that TUR.  AND, as was pointed out, it is still
possible that the device will change state in between the TUR and the READ,
so the TUR could still return GOOD and the READ return a CHECK CONDITION.
If the device is NOT able to process a READ, then when the TUR comes in, the
device returns CHECK CONDITION - NOT READY - INITIALIZING COMMAND REQUIRED. 
The host sends START UNIT.  When the START UNIT completes the host sends the
READ (it might also resend the TUR before sending the READ).  If the device
needs time to get ready, it takes that time during the processing of the
START UNIT command.
Not complex - just 2 cases.  GOOD or INITIALIZING COMMAND REQUIRED.
		Fred Knight
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org>
[mailto:owner-t10 at t10.org<mailto:owner-t10 at t10.org>] On Behalf Of Pat LaVarre
Sent: Tuesday, November 27, 2012 7:27 PM
To: Matthew Jacob
Cc: Gerry Houlder; T10 Reflector
Subject: Re: Behavior of TEST UNIT READY command in idle and standby power
conditions
Of course I trust you all to ask me to sign out if I'm tangent'ing
un-entertainingly ...
...
Q: How could we encourage opinion to converge on such a question?
This Option for Check Condition/ Not Ready from Tur is, by its apparent
crowd-sourced design, an escape from simpler models, a way of allowing the
Target to fall into a state where it needs a Start Unit signal from the host.
With that option left open, Scsi is less simple and more flexible. Thus Scsi
is Scsi, not Ata. Targets that don't need that complexifying option
interoperate more broadly, but naive Hosts then fall unknowing into
supporting only those simpler Targets.
Can we gather votes around simplifying Scsi? Either radically to exclude the
Targets weirdly slow to return from Low Power, or inclusively to burden even
the more common and otherwise simpler quick-to-return targets with the Low
Power Check Condition? Or should we leave Scsi as conflicted with itself as
it always has been here?
...
Like Test Unit Ready has always been intrinsically paradoxical with itself. I
mean, just suppose the Target transitions to Low Power in the narrow time
window before the last Test Unit Ready or Request Sense Poll and the arrival
of a Read Cdb. Well then the Read must handle that condition. So tell me
again what the point of the Poll was? It's just to spend power to help
pretend that the host can handle spontaneous Target transitions to Low Power,
right?
The simplest kind of Scsi, the most power efficient, would forbid the host
poll on these inescapably logical grounds. Q: Poll with Test Unit Ready? A:
No. Q: Poll with Request Sense? A: No. Q: Cope with slow Target? A: Yes. Like
go exercise the discovery features, new in this last decade or two, that help
the host guess how unresponsive a Target might acceptably be, in seconds
elapsed.


From p.lavarre at ieee.org  Thu Nov 29 10:48:31 2012
From: p.lavarre at ieee.org (Pat LaVarre)
Date: Thu, 29 Nov 2012 10:48:31 -0800
Subject: Behavior of TEST UNIT READY command in idle and standby power conditions
Message-ID: <mailman.366.1441607379.22528.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Pat LaVarre <p.lavarre at ieee.org>
*
I think this thread launched by asking, is the polling for Kcq x20402
Initializing Command Required something we could simplify in some
fresh creative way?
Could we eliminate it, require it, code it always as Request Sense,
code it always as Test Unit Ready, include it in every Target's
Stopped state?
Or is it as simple as it can be already? More responsive targets don't
want it, less responsive targets need it, we somehow can't afford to
simplify our way thru that please-everyone contradiction?
> You have lots of choices (some of which work better in some circumstances
than others).
>
> I guess, what I?m saying, is that the answer isn?t a simple black or white
> (always GOOD, or always CHECK CONDITION).  Sometimes,
> you have to evaluate your internal situation and
> make a decision as to which response is appropriate for that situation.
(-: And again Fred says better than any of us what so many of us know
but few can say well.
Those sometime's happen often. That's how Scsi Interoperability is
nothing like Simple, instead Scsi works well only when enough us come
to agree in the code we ship as Initiators and Targets over what
Polite Scsi is.
The Scsi Aftermarket in particular measurably concretely commercially
rewards the Target for guessing well how the Initiator will
misunderstand. Like notice how we hear more of Interoperability
puzzles from Target people here in T10.Org email, not so much from
Initiator people. Targets that guess well just work better in the
Aftermarket, they beat out the others, even an earlier generation from
the same vendor, because they give less hassle to the Aftermarket
customers who add Targets to Initiators.
I'm less confident about how guessing well plays in the compatibility
labs of Enterprise Scsi. I've mostly seen more reasonably complete
specifications and qualifications up there, less room for guessing,
less occasion for the Initiator to be foolishly thinking of one kind
of Target while actually working with another, margin enough to pay
for thoughtful design in advance.
> I?m suggesting that
> you forget about your internal state for just a minute and
> focus on the visible behavior instead ...
> remember, these are models ...SCSI has always been
> more about the visible behavior than actual verifiable internal state.
Yes exactly.
> Yes, I know, engineering sacrilege.
Eh? Sacrilege? To whom? When? Why?
Isn't the win for this seeing of SCSI as an Interoperability Model
well established
in Postel's social engineering paradox nutshell
= """Be conservative in what you do, be liberal in what you accept
|from others."""
= ~~~ We all should code workarounds for people acting foolishly,
after failing to persuade them to change
= ~~~ An opaque bridge not liberal in what it accepts, a transparent
bridge not conservative in what it sends, Q E D no bridge delivers as
much interoperability as it appears to promise.
?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Mark.Evans at wdc.com  Fri Nov 30 14:46:43 2012
From: Mark.Evans at wdc.com (Mark Evans)
Date: Fri, 30 Nov 2012 22:46:43 +0000
Subject: SBC-3 revisions 34 and 34a
Message-ID: <mailman.367.1441607379.22528.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211300_f.htm">HTML-formatted message</a>

Hello all,
I've just posted two drafts of SBC-3 to the T10 website:  revision 34 and
revision 34a.  Both revisions include more than 150 pages of proposals
accepted at the last T10 meeting and numerous other changes, many based on
email that I received.	Revision 34 has most of the changes identified with
track text edits and change bars enabled.  Revision 34a has all of the text
edits accepted and change bars cleared.  There were over 3500 text edits
accepted.  In addition, revision 34a includes several editorial and
formatting corrections, many of which were artifacts of accepting the change
tracking.
Particularly for those of you who had proposals included in these revisions,
please review the changes in these drafts, and call or send an email to me if
you have any comments.	Also, please make any comments that you may have
relative to revision 34a.  My plan is to include the appropriate input I
receive over the next several days in a new revision, and submit that draft
for letter ballot next Friday.
Regards,
Mark Evans
Western Digital Corporation