From alvin.cox at seagate.com  Wed Jan  2 10:44:22 2013
From: alvin.cox at seagate.com (Alvin Cox)
Date: Wed, 2 Jan 2013 12:44:22 -0600
Subject: SAS PHY call 1/4
Message-ID: <mailman.0.1441607388.22530.t10@sandbox.t10.org>

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

Does anyone have material to present? I do not have any updates, but plan
to have something for the F2F.
Let me know by 5pm CST today. I will send a notice at that time regarding
the status of the conference call.
-- 
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809
Office 405-392-3738
E-Mail	alvin.cox at seagate.com


From kdbutt at us.ibm.com  Wed Jan  2 12:24:57 2013
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 2 Jan 2013 13:24:57 -0700
Subject: Extended Copy REGISTER AND MOVE segment 15h
Message-ID: <mailman.1.1441607388.22530.t10@sandbox.t10.org>

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

In looking at Extended Copy segment descriptors, 6.4.6.18 Third party 
persistent reservations source I_T nexus function it appears that there is 
no way to indicate the TYPE of persistent reservation that the REGISTER 
AND MOVE persistent reservation is to create.  The SCOPE is obviously 
Logical Unit since that is the only scope that currently exists, but for 
TYPE it appears that each implementer is left to divine what is desired.
Am I missing something?
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 alvin.cox at seagate.com  Wed Jan  2 13:01:48 2013
From: alvin.cox at seagate.com (Alvin Cox)
Date: Wed, 2 Jan 2013 15:01:48 -0600
Subject: SAS PHY teleconference reminder: i/4/2012, 10:00 am CST
Message-ID: <mailman.2.1441607388.22530.t10@sandbox.t10.org>

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

Agenda:
Mathieu has new proposed crosstalk limits for Rx compliance testing and new
DFE coefficient limits.
Additional items.
Meeting logistics I have the settings corrected so the webex should work
properly and call you back. The call back does not support call/answer/ext.
#, only direct lines.
Topic: SAS-3
Date: Every Thursday, from Thursday, January 3, 2013 to Thursday, January
3, 2013
Time: 10:00 am, Central Standard Time (Chicago, GMT-06:00)
Meeting Number: 827 988 093
Meeting Password: sas12gbps
-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
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
-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
1. Provide your number when you join the meeting to receive a call back.
Alternatively, you can call one of the following numbers:
SeaTel: 8-844-1000
United States: 1-952-230-1270
US Toll-Free: 1-855-856-8765
Singapore: 65-6485-3969
China-Beijing: 86-10-5875-1983
China-Shanghai: 86-21-6141-6283
China-Shenzhen: 86-755-2547-1583
China-Suzhou: 86-512-6273-5995
China-Wuxi: 86-510-8527-3993
Korea-Suwon: 82-31-8025-6006
Malaysia-Penang: 60-4-291-3598
Malaysia-Johore: 60-7-555-6767
Thailand-Teparuk: 66-2-715-7878
Thailand-Korat: 66-44-703599
Taiwan-Taipei: 886-2-2514-2211
2. Follow the instructions that you hear on the phone.
Your Cisco Unified MeetingPlace meeting ID: 827 988 093
-------------------------------------------------------
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
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.
-- 
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809
Office 405-392-3738
E-Mail	alvin.cox at seagate.com


From Elliott at hp.com  Wed Jan  2 21:53:04 2013
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Thu, 3 Jan 2013 05:53:04 +0000
Subject: Running Adobe FrameMaker 10 in 2013
Message-ID: <mailman.3.1441607388.22530.t10@sandbox.t10.org>

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

Adobe FrameMaker 10 won't run in 2013 without a patch...
"Issue
Since January 1, 2013 0000 hrs, FrameMaker 10 users started getting an error:
"Licensing for this product has expired." This error prevents FrameMaker 10
|from launching.
Fix
Based on your FrameMaker 10 (FrameMaker 10\Technical Communication Suite 3 or
FrameMaker 10.0.1\Technical Communication Suite 3.5) version, install one of
the following updates."
See http://helpx.adobe.com/framemaker/kb/cant-launch-framemaker-10.html
---
Rob Elliott, HP Server Storage


From kdbutt at us.ibm.com  Thu Jan  3 09:31:18 2013
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 3 Jan 2013 10:31:18 -0700
Subject: Running Adobe FrameMaker 10 in 2013
Message-ID: <mailman.4.1441607388.22530.t10@sandbox.t10.org>

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

Rob,
Thanks!  This probably saved me a lot of time and research since I had 
this problem too.
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:	"Elliott, Robert (Server Storage)" <Elliott at hp.com>
To:	"t10 at t10.org" <t10 at t10.org>, 
Date:	01/02/2013 11:20 PM
Subject:	Running Adobe FrameMaker 10 in 2013
Sent by:	owner-t10 at t10.org
Adobe FrameMaker 10 won?t run in 2013 without a patch...
"Issue 
Since January 1, 2013 0000 hrs, FrameMaker 10 users started getting an 
error: ?Licensing for this product has expired.? This error prevents 
FrameMaker 10 from launching.
Fix 
Based on your FrameMaker 10 (FrameMaker 10\Technical Communication Suite 3 
or FrameMaker 10.0.1\Technical Communication Suite 3.5) version, install 
one of the following updates."
See http://helpx.adobe.com/framemaker/kb/cant-launch-framemaker-10.html 
---
Rob Elliott, HP Server Storage


From lohmeyer at t10.org  Sat Jan  5 23:01:27 2013
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 6 Jan 2013 00:01:27 -0700
Subject: Recent T10 documents uploaded since 2012/12/30
Message-ID: <mailman.5.1441607388.22530.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC-4 Add reporting of unrecoverable errors that aren;t reassigned
(by: Gerald Houlder)
T10/12-402r2   Uploaded: 2013/01/04   63412 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-402r2.pdf
SPC5: Conglomerate Logical Unit Management
(by: Frederick Knight)
T10/13-002r0   Uploaded: 2013/01/04   209179 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-002r0.pdf
SAS-3 PHY: Receiver Stress Crosstalk Limits
(by: Mathieu Gagnon)
T10/13-021r0   Uploaded: 2013/01/04   633937 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-021r0.pdf
Working Drafts
--------------
(Report generated on 2013/01/06 at 00:01:27)
*
* 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  Tue Jan  8 17:00:25 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Wed, 9 Jan 2013 01:00:25 +0000
Subject: Recetion Reminder tonight at 6:30
Message-ID: <mailman.6.1441607388.22530.t10@sandbox.t10.org>

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

For those that are here for T10 week, we have a reception in Salon D at 6:30.
 I will be raffling off some passports and mybooks...
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.


From lohmeyer at t10.org  Wed Jan  9 12:09:22 2013
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 09 Jan 2013 13:09:22 -0700
Subject: Draft CAP minutes posted
Message-ID: <mailman.7.1441607388.22530.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 January 7-8, 2013 CAP working group meeting are
available at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-022r0.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 Jan  9 12:31:30 2013
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 09 Jan 2013 13:31:30 -0700
Subject: Draft SAS Protocol minutes posted
Message-ID: <mailman.8.1441607388.22530.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 January 9, 2013 SAS Protocol working group meeting
are
available at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-023r0.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 Jan  9 12:33:13 2013
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 09 Jan 2013 13:33:13 -0700
Subject: Fwd: [Chairs] FW: ANSI AIF - ISO Supplement for iPhone or iPad
Message-ID: <mailman.9.1441607388.22530.t10@sandbox.t10.org>

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

>From: "Barra, Lynn" <lbarra at itic.org>
>To: "chairs at standards.incits.org" <chairs at standards.incits.org>,
>	 "irs at standards.incits.org" <irs at standards.incits.org>,
>	 "vice-chairs at standards.incits.org"
<vice-chairs at standards.incits.org>
>Sender: "chairs at standards.incits.org" <chairs at standards.incits.org>
>Date: Wed, 9 Jan 2013 13:08:50 -0700
>Subject: [Chairs] FW: ANSI AIF - ISO Supplement for iPhone or iPad
>
>To INCITS Officers ?
> 
>Please share the information below with your committee members.
> 
> 
>From: Henry Cheung
>Sent: Monday, January 07, 2013 11:55 AM
>To: All AIF Members
>Subject: ANSI AIF - ISO Supplement for iPhone or iPad
> 
>To:
>ANSI ISO Forum (AIF) Members
> 
>From:
>Joseph Tretler Jr.
>ANSI Sr. Director
>International Technical Programs and Services
> 
>We are pleased to announce the availability of the Supplement to the ISO/IEC
Directives, Part 1 in EPUB, which means that it is accessible using your
iPhone or iPad. 
> 
>What you need
>?	   Web browser
>?	   iBooks which you can download for free from the App Store
> 
>What to do
>1)    Go to <www.iso.org/directives">http://www.iso.org/directives>www.iso.org/directives on your
Apple device using your browser
>2)    Under "Official Rules" tap "ISO/IEC Directives, Part 1 and
Consolidated ISO Supplement"
>3)    This will open the ISOTC folder with the Supplement in various formats
- tap on the EPUB file
>4)    You will be asked in which format you wish to open the file -- choose
iBooks. Note it may take a few minutes to load.
>5)    The Supplement will appear in the Library - tap on it to open. Note
that the file may take a few seconds to load every time you open it.
> 
>The availability of the Supplement in EPUB will be announced in the next
edition of the TMB Communiqu?, which is scheduled to be sent out 1 week after
the Feb TMB meeting. 
> 
>Thank you.
> 
> 
> 
> 
><http://www.standardsboostbusiness.org/&gt;
>cid:image003.jpg at 01CDDEA6.B7083C00
>
> 
> 
>
--
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


From Elliott at hp.com  Wed Jan  9 16:31:01 2013
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Thu, 10 Jan 2013 00:31:01 +0000
Subject: 12-458 comments from SOP PQI WG meeting
Message-ID: <mailman.10.1441607388.22530.t10@sandbox.t10.org>

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

Here are the comments recorded on 12-458 during the SOP PQI WG meeting, for
people to think about for tomorrow morning:
Without IQ added everywhere, ABORT TASK and QUERY TASK must be sent down the
same IQ as the command that they are affecting.
If IQ were added alongside the REQUEST IDENTIFIER, then the ABORT TASK and
QUERY TASK could be sent down other IQs.  However, the initiator would need
to implement Request Fence to ensure that the other IQs have been consumed
before sending the ABORT TASK or QUERY TASK, to avoid a race condition where
the ABORT TASK or QUERY TASK arrives before the command that it is trying to
affect.
For ABORT TASK SET, CLEAR TASK SET, and LOGICAL UNIT RESET, the initiator
must implement Request Fence and wait for the other IQs to be consumed before
sending the TMF.  Adding IQ alongside REQUEST IDENTIFIER doesn't help this.
Proposals:
1. add "send ABORT TASK and QUERY TASK down same IQ" rule   (or every IQ, if
it doesn't remember... ugly for QUERY TASK)
2 a) add Request Fence rules.  Scope=I_T_L_Q means #1.	Scope=I_T_L or I_T
means initiator port wait for all other IQs to be consumed (based on IQ CI)
before sending the command or TMF specifying Request Fence.
2 b) Make the device check all the PIs when it receives a command or TMF that
affects other commands (i.e. implies Request Fence). Must decode the command
or TMF to make this decision.  Drain all those other IQs before processing
this command or TMF.  The initiator is required to post all affected commands
to the other queues for this to work - cannot be stuck pre-queue.  So this
means Request Fence just forces the commands to be produced (visible via PI),
not consumed (CI).  The driver can also interpret the TMF itself and e.g.
abort commands that aren't produced yet.
3. add OQ alongside Request ID for ABORT TASK and QUERY TASK to effectively
expand the number of tags
4. add optional IQ alongside Request ID for ABORT TASK and QUERY TASK so they
can be sent down different IQs than the command they are affecting.
5 a) Do not support multiple initiators sharing one function.  Use SR-IOV for
that; or
5 b) add an Initiator Identifier during queue creation that can be used to
identify sets of IQs as related, and send the TMF down any IQ within the set.
 Since there is only one admin queue pair, a hypervisor would have to handle
the queue creation.


From alvin.cox at seagate.com  Thu Jan 10 09:07:54 2013
From: alvin.cox at seagate.com (Alvin Cox)
Date: Thu, 10 Jan 2013 11:07:54 -0600
Subject: SAS PHY teleconference schedule
Message-ID: <mailman.11.1441607388.22530.t10@sandbox.t10.org>

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

Date: Every Thursday, from Thursday, January 17, 2013 to Thursday, March 7,
2013, except February 7.
Time: 10:00 am, Central Standard Time (Chicago, GMT-06:00) Agenda to be
determined.
Other cancellation dates may be made based on need to review material .
Agenda:
TBD
Logistics (Audio is included in the Webex. Please log into Webex prior to
call in if possible.):
Topic: SAS-3
Date: Every Thursday, from Thursday, January 17, 2013 to Thursday, March 7,
2013
Time: 10:00 am, Central Standard Time (Chicago, GMT-06:00)
Meeting Number: 827 988 093
Meeting Password: sas12gbps
-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
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".
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
-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
1. Provide your number when you join the meeting to receive a call back.
Alternatively, you can call one of the following numbers:
SeaTel: 8-844-1000
United States: 1-952-230-1270
US Toll-Free: 1-855-856-8765
Singapore: 65-6485-3969
China-Beijing: 86-10-5875-1983
China-Shanghai: 86-21-6141-6283
China-Shenzhen: 86-755-2547-1583
China-Suzhou: 86-512-6273-5995
China-Wuxi: 86-510-8527-3993
Korea-Suwon: 82-31-8025-6006
Malaysia-Penang: 60-4-291-3598
Malaysia-Johore: 60-7-555-6767
Thailand-Teparuk: 66-2-715-7878
Thailand-Korat: 66-44-703599
Taiwan-Taipei: 886-2-2514-2211
2. Follow the instructions that you hear on the phone.
Your Cisco Unified MeetingPlace meeting ID: 827 988 093
-------------------------------------------------------
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=MRS2&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
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.
-- 
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809
Office 405-392-3738
E-Mail	alvin.cox at seagate.com


From curtis.stevens at wdc.com  Thu Jan 10 09:17:48 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 10 Jan 2013 17:17:48 +0000
Subject: SOPQI Telecon
Message-ID: <mailman.12.1441607388.22530.t10@sandbox.t10.org>

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

14-Jan-2013 @12:30pm PT - Continue SOP Letter Ballot comment resolution
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 747 023 040
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=747023040
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 Jan 10 09:20:43 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 10 Jan 2013 17:20:43 +0000
Subject: SOPQI Telecon
Message-ID: <mailman.13.1441607388.22530.t10@sandbox.t10.org>

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

28-Jan-2013 @12:30pm PT - Continue SOP Letter Ballot comment resolution
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 746 378 475
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=746378475
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 Jan 10 09:26:47 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 10 Jan 2013 17:26:47 +0000
Subject: SOPQI Telecon
Message-ID: <mailman.14.1441607388.22530.t10@sandbox.t10.org>

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

11-Feb-2013 @12:30pm PT - Continue SOP & PQI Letter Ballot comment resolution
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 746 433 666
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=746433666
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 Jan 10 09:24:11 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 10 Jan 2013 17:24:11 +0000
Subject: SOPQI Telecon
Message-ID: <mailman.15.1441607388.22530.t10@sandbox.t10.org>

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

4-Feb-2013 @12:30pm PT - Continue SOP Letter Ballot comment resolution
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 748 112 194
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=748112194
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 Jan 10 09:28:59 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 10 Jan 2013 17:28:59 +0000
Subject: SOPQI Telecon
Message-ID: <mailman.16.1441607388.22530.t10@sandbox.t10.org>

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

18-Feb-2013 @12:30pm PT - Continue SOP & PQI Letter Ballot comment resolution
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 744 974 489
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=744974489
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 Jan 10 09:30:43 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 10 Jan 2013 17:30:43 +0000
Subject: SOPQI Telecom
Message-ID: <mailman.17.1441607388.22530.t10@sandbox.t10.org>

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

25-Feb-2013 @12:30pm PT - Continue SOP & PQI Letter Ballot comment resolution
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 744 534 639
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=744534639
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 roweber at ieee.org  Thu Jan 10 09:34:03 2013
From: roweber at ieee.org (Ralph Weber)
Date: Thu, 10 Jan 2013 11:34:03 -0600
Subject: 21 Jan PQI Letter Ballot concall (12:30-2:30 PST)
Message-ID: <mailman.18.1441607388.22530.t10@sandbox.t10.org>

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1301107_130121_pqi.ics">130121_pqi.ics</a>

Hello ,
Ralph Weber invites you to attend this online meeting.
Topic: PQI Letter Ballot Review
Date: Monday, January 21, 2013
Time: 2:30 pm, Central Standard Time (Chicago, GMT-06:00)
Meeting Number: 741 795 277
Meeting Password: (This meeting does not require a password.)


From curtis.stevens at wdc.com  Thu Jan 10 09:32:49 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 10 Jan 2013 17:32:49 +0000
Subject: SOPQI Telecom
Message-ID: <mailman.19.1441607388.22530.t10@sandbox.t10.org>

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

4-Mar-2013 @12:30pm PT - Continue SOP & PQI Letter Ballot comment resolution
CURTIS STEVENS invites you to an online meeting using WebEx.
Meeting Number: 742 644 597
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=742644597
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 john.lohmeyer at lsi.com  Thu Jan 10 10:08:13 2013
From: john.lohmeyer at lsi.com (John Lohmeyer)
Date: Thu, 10 Jan 2013 11:08:13 -0700
Subject: Test email - please ignore
Message-ID: <mailman.20.1441607388.22530.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <john.lohmeyer at lsi.com>
*
--
John Lohmeyer		       Email: john.lohmeyer at lsi.com
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		 Fax: +1-719-533-7183
Colo Spgs, CO 80907		Cell: +1-719-338-1642
*
* 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  Sat Jan 12 15:39:40 2013
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Sat, 12 Jan 2013 23:39:40 +0000
Subject: Extended Copy REGISTER AND MOVE segment 15h
Message-ID: <mailman.21.1441607388.22530.t10@sandbox.t10.org>

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

When I read the REGISTER AND MOVE description I see:
In response to a PERSISTENT RESERVE OUT command with a REGISTER AND MOVE
service action the
device server shall perform a register and move by doing the following as an
uninterrupted series of actions:
a)     process the APTPL bit;
b)	ignore the contents of the SCOPE and TYPE fields;
c)	 ......
So, what do you expect the TYPE field to do?  All REGISTER AND MOVE does is
to REGISTER an initiator, and then MOVE the existing reservation.
		Fred
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
Sent: Wednesday, January 02, 2013 3:25 PM
To: T10 Reflector
Subject: Extended Copy REGISTER AND MOVE segment 15h
In looking at Extended Copy segment descriptors, 6.4.6.18 Third party
persistent reservations source I_T nexus function it appears that there is no
way to indicate the TYPE of persistent reservation that the REGISTER AND MOVE
persistent reservation is to create.  The SCOPE is obviously Logical Unit
since that is the only scope that currently exists, but for TYPE it appears
that each implementer is left to divine what is desired.
Am I missing something?
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 Jan 12 23:01:22 2013
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 13 Jan 2013 00:01:22 -0700
Subject: Recent T10 documents uploaded since 2013/01/06
Message-ID: <mailman.22.1441607388.22530.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-251r8   Uploaded: 2013/01/10   621374 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-251r8.pdf
SAM-5 Move multiple port model from SPC-4
(by: Rob Elliott)
T10/12-335r2   Uploaded: 2013/01/08   211400 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-335r2.pdf
SPC-5 Obsolete Printer Devices
(by: Paul Suhler)
T10/12-362r1   Uploaded: 2013/01/07   16729 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-362r1.pdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r7   Uploaded: 2013/01/09   8167717 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r7.pdf
SOP Letter Ballot Comments
(by: Curtis Stevens)
T10/12-379r7   Uploaded: 2013/01/09   514163 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-379r7.zip
SPL-3 Add reporting of POWER DISABLE signal support
(by: Gerald Houlder)
T10/12-401r2   Uploaded: 2013/01/08   113276 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-401r2.pdf
Add Not Ready ASCs for Subsidiary Logical Units
(by: David L. Black, Murali Rajagopal)
T10/12-415r3   Uploaded: 2013/01/08   14936 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-415r3.pdf
SBC-4 Define new background scan status value
(by: Gerald Houlder)
T10/12-427r1   Uploaded: 2013/01/08   52940 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-427r1.pdf
SAS-3: Passive Cable S-parameter Limit Proposal
(by: Darian Schulz)
T10/12-435r1   Uploaded: 2013/01/08   3346565 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-435r1.pdf
SAS-3: Passive Cable S-parameter Limit Proposal
(by: Darian Schulz)
T10/12-435r2   Uploaded: 2013/01/08   3347225 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-435r2.pdf
SAM-5 Task management function description tweaks
(by: Rob Elliott)
T10/13-004r1   Uploaded: 2013/01/08   183462 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-004r1.pdf
SBC-3 Contents for Product Type Identification Table
(by: John Geldman)
T10/13-011r0   Uploaded: 2013/01/06   111638 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-011r0.pdf
SAS3-PHY: SAS3_EYEOPENING script release
(by: Mathieu Gagnon)
T10/13-018r1   Uploaded: 2013/01/08   225629 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-018r1.pdf
SAS3-PHY: SAS3_EYEOPENING script release
(by: Mathieu Gagnon)
T10/13-018r1   Uploaded: 2013/01/08   35589438 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-018r1.zip
Logical Unit Groups (aka Conglomerates) in SAM-5 and SPC-4
(by: Ralph Weber)
T10/13-020r1   Uploaded: 2013/01/10   177017 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-020r1.pdf
SAS-3 PHY: Receiver Stress Crosstalk Limits
(by: Mathieu Gagnon)
T10/13-021r1   Uploaded: 2013/01/08   482601 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-021r1.pdf
Minutes of CAP Working Group - January 7-8, 2013
(by: Weber & Lohmeyer)
T10/13-022r0   Uploaded: 2013/01/09   62788 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-022r0.htm
Minutes of CAP Working Group - January 7-8, 2013
(by: Weber & Lohmeyer)
T10/13-022r0   Uploaded: 2013/01/09   151802 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-022r0.pdf
Minutes of SAS Protocol Working Group - January 9, 2013
(by: Weber & Lohmeyer)
T10/13-023r0   Uploaded: 2013/01/09   31574 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-023r0.htm
Minutes of SAS Protocol Working Group - January 9, 2013
(by: Weber & Lohmeyer)
T10/13-023r0   Uploaded: 2013/01/09   90854 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-023r0.pdf
Next Gen. (SAS-4) HDD Connector Proposal
(by: Doron Lapidot)
T10/13-028r0   Uploaded: 2013/01/09   1746873 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-028r0.pdf
SPC-4: Device Internal Status Dump
(by: Frederick Knight)
T10/13-029r0   Uploaded: 2013/01/08   219180 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-029r0.pdf
SAS-3 PHY: Crosstalk simulation and measurement updates
(by: Mathieu Gagnon)
T10/13-031r0   Uploaded: 2013/01/08   279147 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-031r0.pdf
SAS-3 PHY: Crosstalk simulation and measurement updates
(by: Mathieu Gagnon)
T10/13-031r1   Uploaded: 2013/01/08   284301 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-031r1.pdf
SAS-3 PHY: Tx device, passive TxRx connections & ISI generator
characteristics
(by: Mathieu Gagnon)
T10/13-032r0   Uploaded: 2013/01/08   364958 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-032r0.pdf
SAS-3 PHY: Tx device, passive TxRx connections & ISI generator
characteristics
(by: Mathieu Gagnon)
T10/13-032r1   Uploaded: 2013/01/08   381669 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-032r1.pdf
SAS-3 addition of Mini SAS HD 16i receptacle connector
(by: Alvin Cox)
T10/13-033r0   Uploaded: 2013/01/08   613325 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-033r0.pdf
Foxconn - Combo PCIe-SAS 3 Connector SI Data
(by: Fred Fons)
T10/13-036r0   Uploaded: 2013/01/08   590688 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-036r0.pdf
Minutes SSC-4 January 09, 2013
(by: Kevin Butt)
T10/13-038r0   Uploaded: 2013/01/10   21348 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-038r0.pdf
T13 Liaison Report to T10
(by: Dan Colegrove)
T10/13-039r0   Uploaded: 2013/01/09   15422 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-039r0.pdf
T13 Liaison Report to T10
(by: Dan Colegrove)
T10/13-039r0   Uploaded: 2013/01/09   14336 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-039r0.ppt
SSC-4 Status Report - January 2013
(by: David Peterson)
T10/13-040r0   Uploaded: 2013/01/10   18402 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-040r0.pdf
STA - T10 Liaison Report January 10, 2013
(by: Marty Czekalski)
T10/13-041r0   Uploaded: 2013/01/10   116925 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-041r0.pdf
SSC-4: Volume Coherency Application example moved to Annex
(by: Kevin Butt)
T10/13-042r0   Uploaded: 2013/01/10   42036 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-042r0.pdf
IETF Liaison Report to T10
(by: David Black)
T10/13-043r0   Uploaded: 2013/01/10   705055 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-043r0.pdf
Agenda for T10 Meeting #114 March 14, 2013
(by: John Lohmeyer)
T10/13-044r0   Uploaded: 2013/01/11   13040 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-044r0.pdf
T10 Project Summary - January 2013
(by: John Lohmeyer)
T10/13-045r0   Uploaded: 2013/01/11   30181 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-045r0.pdf
Jeopardy Letter for March 2013 meeting
(by: John Lohmeyer)
T10/13-046r0   Uploaded: 2013/01/10   31888 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-046r0.pdf
Working Drafts
--------------
(Report generated on 2013/01/13 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 kdbutt at us.ibm.com  Mon Jan 14 12:57:50 2013
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 14 Jan 2013 13:57:50 -0700
Subject: Extended Copy REGISTER AND MOVE segment 15h
Message-ID: <mailman.23.1441607388.22530.t10@sandbox.t10.org>

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

Fred,
Thank you for your response.  What threw me is that Table 216 ? PERSISTENT 
RESERVE OUT service actions and valid parameters has a row for REGISTER 
AND MOVE and lists under the TYPE column "valid".  After reading the text, 
though, it is clear that the TYPE field is "ignored" not "valid".
Ralph,
If this isn't already a letter ballot comment against SPC-4 I would like 
to add it.  That is, correct Table 216 ? PERSISTENT RESERVE OUT service 
actions and valid parameters to show "ignored" for the TYPE field for a 
service action of REGISTER AND MOVE.
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:	"Knight, Frederick" <Frederick.Knight at netapp.com>
To:	Kevin D Butt/Tucson/IBM at IBMUS, T10 Reflector <t10 at t10.org>, 
Date:	01/12/2013 04:39 PM
Subject:	RE: Extended Copy REGISTER AND MOVE segment 15h
When I read the REGISTER AND MOVE description I see:
In response to a PERSISTENT RESERVE OUT command with a REGISTER AND MOVE 
service action the
device server shall perform a register and move by doing the following as 
an uninterrupted series of actions:
a)     process the APTPL bit;
b)	ignore the contents of the SCOPE and TYPE fields;
c)	 ??
So, what do you expect the TYPE field to do?  All REGISTER AND MOVE does 
is to REGISTER an initiator, and then MOVE the existing reservation.
		Fred
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Wednesday, January 02, 2013 3:25 PM
To: T10 Reflector
Subject: Extended Copy REGISTER AND MOVE segment 15h
In looking at Extended Copy segment descriptors, 6.4.6.18 Third party 
persistent reservations source I_T nexus function it appears that there is 
no way to indicate the TYPE of persistent reservation that the REGISTER 
AND MOVE persistent reservation is to create.  The SCOPE is obviously 
Logical Unit since that is the only scope that currently exists, but for 
TYPE it appears that each implementer is left to divine what is desired. 
Am I missing something? 
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 at seagate.com  Tue Jan 15 12:10:41 2013
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Tue, 15 Jan 2013 14:10:41 -0600
Subject: Question about CLEAR TASK SET and ABORT TASK SET
Message-ID: <mailman.24.1441607388.22530.t10@sandbox.t10.org>

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

I have a question about the effects of the ABORT TASK SET and CLEAR TASK
SET functions.
The scope of these functions is affected by the TST setting (i.e., whether
the device server maintains a separate task set for each I_T nexus
(TST=001b) or puts all commands from all I_T nexes in the same task set
(TST=000b).
My historical understanding of these functions is:
   - ABORT TASK SET is supposed to abort all commands within the defined
   task set. If TST=000b, this would be all commands from all I_T nexes; if
   TST=001b, this would be all commands from a particular I_T nexus.
   - CLEAR TASK SET is supposed to clear all commands in all task sets,
   regardless of TST bit setting.
The SAM-5 wording regarding these functions seem to describe these
functions differently.
   -  The ABORT TASK SET wording seems to require aborting command for a
   single I_T nexus, which is part of the task set (assuming the device
server
   has outstanding commands from several I_T nexes) if TST=000b and an entire
   task set if TST=001b.
   - SAM-5 wording for CLEAR TASK SET says it only affects one task set, so
   if TST=000b then it affects all commands and if TST=001b then only the
   commands in a single task set (i.e., from one I_T nexus) are affected.
   - With the current SAM-5 definitions, neither ABORT TASK SET or CLEAR
   TASK SET will abort all commands in all task sets if TST=0001b. This seems
   wrong.
I think the current SAM-5 wording of these functions is not the best. Where
do we go from here?


From Mark.Evans at wdc.com  Tue Jan 15 15:35:53 2013
From: Mark.Evans at wdc.com (Mark Evans)
Date: Tue, 15 Jan 2013 23:35:53 +0000
Subject: Question about CLEAR TASK SET and ABORT TASK SET
Message-ID: <mailman.25.1441607388.22530.t10@sandbox.t10.org>

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

Hi Gerry,
Someplace along the line I think we got off the beam.  Here is some text from
SAM-1 with some comments:
a)     "An ABORT TASK SET function terminates all tasks for the initiator on
the specified task set of the target."	However, there is no definition in
SAM-1 as to what a "specified task set" is or how it's defined.  The TST
field wasn't defined until SPC-2r2 over two years later; and
b)    "The CLEAR TASK SET function terminates all tasks for all initiators on
the specified task set of the target."	Again, there is no definition in
SAM-1 as to what a "specified task set" is.
It seems to me that, since there wasn't any definition of what a "specified
task set" was, that the intent was as you described it, and, I think how many
of us understand it (i.e., CLEAR TASK SET clears all commands for all
initiators).
It looks like this stuff stayed out of sync, with the final insult being a
change that was made in SAM-4r12 based on proposal 06-026r4 from Rob Elliot.
Maybe Rob can reconcile all of this, but it looks to me like we need to
change the definitions in SAM-5 to something like:
7.3 ABORT TASK SET
.....
Description:
This function shall be supported by all logical units.
If the task manager maintains one task set for all I_T nexuses as specified
by the TST field in the Control mode page (see SPC-4), then the task manager
shall abort all commands in the task set (i.e., the equivalent of a CLEAR
TASK SET task management function).  If the task manager maintains one task
set for each I_T nexus as specified by the TST field, then the task manager
shall abort all commands in the task set that were received on the specified
I_T nexus.
All pending status and sense data for the commands that were aborted shall be
cleared. Other previously established conditions, including mode parameters,
reservations, and ACA shall not be changed by the ABORT TASK SET function.
All SCSI transport protocol standards shall support the ABORT TASK SET task
management function.
.....
7.5 CLEAR TASK SET
.....
Description:
This function shall be supported by all logical units.
The task manager shall abort all commands in all task sets as described in
5.6.
All pending status and sense data for the task set shall be cleared. Other
previously established conditions, including mode parameters, reservations,
and ACA shall not be changed by the CLEAR TASK SET function.
All SCSI transport protocol standards shall support the CLEAR TASK SET task
management function.
.....
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
Home office: 541.563.7880
Cell: 408.391.7805
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Tuesday, January 15, 2013 12:11 PM
To: T10 Reflector
Subject: Question about CLEAR TASK SET and ABORT TASK SET
I have a question about the effects of the ABORT TASK SET and CLEAR TASK SET
functions.
The scope of these functions is affected by the TST setting (i.e., whether
the device server maintains a separate task set for each I_T nexus (TST=001b)
or puts all commands from all I_T nexes in the same task set (TST=000b).
My historical understanding of these functions is:
  *   ABORT TASK SET is supposed to abort all commands within the defined
task set. If TST=000b, this would be all commands from all I_T nexes; if
TST=001b, this would be all commands from a particular I_T nexus.
  *   CLEAR TASK SET is supposed to clear all commands in all task sets,
regardless of TST bit setting.
The SAM-5 wording regarding these functions seem to describe these functions
differently.
  *    The ABORT TASK SET wording seems to require aborting command for a
single I_T nexus, which is part of the task set (assuming the device server
has outstanding commands from several I_T nexes) if TST=000b and an entire
task set if TST=001b.
  *   SAM-5 wording for CLEAR TASK SET says it only affects one task set, so
if TST=000b then it affects all commands and if TST=001b then only the
commands in a single task set (i.e., from one I_T nexus) are affected.
  *   With the current SAM-5 definitions, neither ABORT TASK SET or CLEAR
TASK SET will abort all commands in all task sets if TST=0001b. This seems
wrong.
I think the current SAM-5 wording of these functions is not the best. Where
do we go from here?


From George.Penokie at lsi.com  Wed Jan 16 07:00:31 2013
From: George.Penokie at lsi.com (Penokie, George)
Date: Wed, 16 Jan 2013 08:00:31 -0700
Subject: Question about CLEAR TASK SET and ABORT TASK SET
Message-ID: <mailman.26.1441607388.22530.t10@sandbox.t10.org>

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

Gerry,
Your understanding is not correct.
The TST setting has no effect on ABORT TASK SET. The same commands are
aborted regardless of the TST setting when an ABORT TASK SET is issued. If
TST is zero there is one task set so then all the commands from the I_T nexus
on which the command was received would be aborted and any commands from
difference I_T nexuses are not aborted. If TST is one then there is one task
set for each I_T nexus so  any time an ABORT TASK SET is received it will
abort all the commands in that task set but not affect any of the commands in
the other task sets.
The TST setting does affect the operation of the CLEAR TASK SET. If the TST
is set to zero, meaning there is one task set, then all the commands in that
task set are cleared regardless of which I_T nexus the command was received
on. However, if the TST is one then there are separate task sets for each I_T
nexus, then a CLEAR TASK SET will only clear the task set to which it is
sent. The effect of this is the same as if an ABORT TASK SET was sent to that
same task set.
The net is that if TST is set to one the ABORT TASK SET and CLEAR TASK SET
will abort the same set of commands.
This effect is clearly called out in footnote c of table 41 in SAM-5 revision
12:
If the TST field is set to 001b (i.e., per I_T nexus) in the Control mode
page (see SPC-4), then there is one task set per I_T nexus As a result, no
other I_T nexuses are affected and CLEAR TASK SET is equivalent to ABORT TASK
SET.
As for history, TST came into existence in SAM-2. In SAM-2 revision 10 the
following paragraph was in the CLEAR TASK SET section:
If the TST field equals 000b in the Control mode page (see SPC-2), the target
shall perform an action equivalent to receiving a series of ABORT TASK
requests from each initiator. If the TST field equals 001b the target shall
perform an action equivalent to receiving a series of ABORT TASK requests
|from only the requesting initiator.
I do not see any problem with the way it is currently worded in SAM-5.
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at lsi.com
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark Evans
Sent: Tuesday, January 15, 2013 5:36 PM
To: Gerry Houlder; T10 Reflector
Subject: RE: Question about CLEAR TASK SET and ABORT TASK SET
Hi Gerry,
Someplace along the line I think we got off the beam.  Here is some text from
SAM-1 with some comments:
a)     "An ABORT TASK SET function terminates all tasks for the initiator on
the specified task set of the target."	However, there is no definition in
SAM-1 as to what a "specified task set" is or how it's defined.  The TST
field wasn't defined until SPC-2r2 over two years later; and
b)    "The CLEAR TASK SET function terminates all tasks for all initiators on
the specified task set of the target."	Again, there is no definition in
SAM-1 as to what a "specified task set" is.
It seems to me that, since there wasn't any definition of what a "specified
task set" was, that the intent was as you described it, and, I think how many
of us understand it (i.e., CLEAR TASK SET clears all commands for all
initiators).
It looks like this stuff stayed out of sync, with the final insult being a
change that was made in SAM-4r12 based on proposal 06-026r4 from Rob Elliot.
Maybe Rob can reconcile all of this, but it looks to me like we need to
change the definitions in SAM-5 to something like:
7.3 ABORT TASK SET
.....
Description:
This function shall be supported by all logical units.
If the task manager maintains one task set for all I_T nexuses as specified
by the TST field in the Control mode page (see SPC-4), then the task manager
shall abort all commands in the task set (i.e., the equivalent of a CLEAR
TASK SET task management function).  If the task manager maintains one task
set for each I_T nexus as specified by the TST field, then the task manager
shall abort all commands in the task set that were received on the specified
I_T nexus.
All pending status and sense data for the commands that were aborted shall be
cleared. Other previously established conditions, including mode parameters,
reservations, and ACA shall not be changed by the ABORT TASK SET function.
All SCSI transport protocol standards shall support the ABORT TASK SET task
management function.
.....
7.5 CLEAR TASK SET
.....
Description:
This function shall be supported by all logical units.
The task manager shall abort all commands in all task sets as described in
5.6.
All pending status and sense data for the task set shall be cleared. Other
previously established conditions, including mode parameters, reservations,
and ACA shall not be changed by the CLEAR TASK SET function.
All SCSI transport protocol standards shall support the CLEAR TASK SET task
management function.
.....
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
Home office: 541.563.7880
Cell: 408.391.7805
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Tuesday, January 15, 2013 12:11 PM
To: T10 Reflector
Subject: Question about CLEAR TASK SET and ABORT TASK SET
I have a question about the effects of the ABORT TASK SET and CLEAR TASK SET
functions.
The scope of these functions is affected by the TST setting (i.e., whether
the device server maintains a separate task set for each I_T nexus (TST=001b)
or puts all commands from all I_T nexes in the same task set (TST=000b).
My historical understanding of these functions is:
 *   ABORT TASK SET is supposed to abort all commands within the defined task
set. If TST=000b, this would be all commands from all I_T nexes; if TST=001b,
this would be all commands from a particular I_T nexus.
 *   CLEAR TASK SET is supposed to clear all commands in all task sets,
regardless of TST bit setting.
The SAM-5 wording regarding these functions seem to describe these functions
differently.
 *    The ABORT TASK SET wording seems to require aborting command for a
single I_T nexus, which is part of the task set (assuming the device server
has outstanding commands from several I_T nexes) if TST=000b and an entire
task set if TST=001b.
 *   SAM-5 wording for CLEAR TASK SET says it only affects one task set, so
if TST=000b then it affects all commands and if TST=001b then only the
commands in a single task set (i.e., from one I_T nexus) are affected.
 *   With the current SAM-5 definitions, neither ABORT TASK SET or CLEAR TASK
SET will abort all commands in all task sets if TST=0001b. This seems wrong.
I think the current SAM-5 wording of these functions is not the best. Where
do we go from here?


From gerry.houlder at seagate.com  Wed Jan 16 07:10:21 2013
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Wed, 16 Jan 2013 09:10:21 -0600
Subject: Question about CLEAR TASK SET and ABORT TASK SET
Message-ID: <mailman.27.1441607388.22530.t10@sandbox.t10.org>

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

Thanks all for your replies to my ABORT TASK SET question. It turns out I
was the only one confused about this. In hindsight I wish the ABORT TASK
SET function had been named ABORT I_T NEXUS instead -- that name would have
been more correctly descriptive.
On Wed, Jan 16, 2013 at 9:00 AM, Penokie, George
<George.Penokie at lsi.com>wrote:
> Gerry,****
>
> ** **
>
> Your understanding is not correct.****
>
> ** **
>
> The TST setting has no effect on ABORT TASK SET. The same commands are
> aborted regardless of the TST setting when an ABORT TASK SET is issued. If
> TST is zero there is one task set so then all the commands from the I_T
> nexus on which the command was received would be aborted and any commands
> from difference I_T nexuses are not aborted. If TST is one then there is
> one task set for each I_T nexus so  any time an ABORT TASK SET is received
> it will abort all the commands in that task set but not affect any of the
> commands in the other task sets.****
>
> ** **
>
> The TST setting does affect the operation of the CLEAR TASK SET. If the
> TST is set to zero, meaning there is one task set, then all the commands in
> that task set are cleared regardless of which I_T nexus the command was
> received on. However, if the TST is one then there are separate task sets
> for each I_T nexus, then a CLEAR TASK SET will only clear the task set to
> which it is sent. The effect of this is the same as if an ABORT TASK SET
> was sent to that same task set. ****
>
> ** **
>
> The net is that if TST is set to one the ABORT TASK SET and CLEAR TASK SET
> will abort the same set of commands.****
>
> ** **
>
> This effect is clearly called out in footnote c of table 41 in SAM-5
> revision 12:****
>
> ** **
>
> If the TST field is set to 001b (i.e., per I_T nexus) in the Control mode
> page (see SPC-4), then there is one task set per I_T nexus As a result, no
> other I_T nexuses are affected and CLEAR TASK SET is equivalent to ABORT
> TASK SET.****
>
> ** **
>
> As for history, TST came into existence in SAM-2. In SAM-2 revision 10 the
> following paragraph was in the CLEAR TASK SET section:****
>
> ** **
>
> If the TST field equals 000b in the Control mode page (see SPC-2), the
> target shall perform an action equivalent to receiving a series of ABORT
> TASK requests from each initiator. If the TST field equals 001b the target
> shall perform an action equivalent to receiving a series of ABORT TASK
> requests from only the requesting initiator.****
>
> ** **
>
> I do not see any problem with the way it is currently worded in SAM-5.****
>
> ** **
>
> Bye for now,****
>
> George Penokie****
>
> ** **
>
> LSI Corporation****
>
> 3033 41 St NW****
>
> Rochester , MN 55901****
>
> ** **
>
> 507-328-9017****
>
> george.penokie at lsi.com****
>
> ** **
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Mark
> Evans
> *Sent:* Tuesday, January 15, 2013 5:36 PM
> *To:* Gerry Houlder; T10 Reflector
> *Subject:* RE: Question about CLEAR TASK SET and ABORT TASK SET****
>
> ** **
>
> Hi Gerry,****
>
> ** **
>
> Someplace along the line I think we got off the beam.  Here is some text
> from SAM-1 with some comments:****
>
> ** **
>
> **a)	   **?An ABORT TASK SET function terminates all tasks for the
> initiator on the specified task set of the target.?  However, there is no
> definition in SAM-1 as to what a ?specified task set? is or how it?s
> defined.  The TST field wasn?t defined until SPC-2r2 over two years later;
> and****
>
> **b)	  **?The CLEAR TASK SET function terminates all tasks for all
> initiators on the specified task set of the target.?	Again, there is no
> definition in SAM-1 as to what a ?specified task set? is.****
>
> ** **
>
> It seems to me that, since there wasn?t any definition of what a
> ?specified task set? was, that the intent was as you described it, and, I
> think how many of us understand it (i.e., CLEAR TASK SET clears all
> commands for all initiators).  ****
>
> ** **
>
> It looks like this stuff stayed out of sync, with the final insult being a
> change that was made in SAM-4r12 based on proposal 06-026r4 from Rob
Elliot.
> ****
>
> ** **
>
> Maybe Rob can reconcile all of this, but it looks to me like we need to
> change the definitions in SAM-5 to something like:****
>
> ** **
>
> *7.3 ABORT TASK SET*
>
> .....****
>
> ** **
>
> Description:****
>
> ** **
>
> This function shall be supported by all logical units.****
>
> ** **
>
> If the task manager maintains one task set for all I_T nexuses as
> specified by the TST field in the Control mode page (see SPC-4), then the
> task manager shall abort all commands in the task set (i.e., the equivalent
> of a CLEAR TASK SET task management function).  If the task manager
> maintains one task set for each I_T nexus as specified by the TST field,
> then the task manager shall abort all commands in the task set that were
> received on the specified I_T nexus.****
>
> ** **
>
> All pending status and sense data for the commands that were aborted shall
> be cleared. Other previously established conditions, including mode
> parameters, reservations, and ACA shall not be changed by the ABORT TASK
> SET function.****
>
> ** **
>
> All SCSI transport protocol standards shall support the ABORT TASK SET
> task management function.****
>
> ?..****
>
> ** **
>
> *7.5 CLEAR TASK SET*
>
> .....****
>
> ** **
>
> Description:****
>
> ** **
>
> This function shall be supported by all logical units.****
>
> ** **
>
> The task manager shall abort all commands in all task sets as described in
> 5.6.****
>
> ** **
>
> All pending status and sense data for the task set shall be cleared. Other
> previously established conditions, including mode parameters, reservations,
> and ACA shall not be changed by the CLEAR TASK SET function.****
>
> ** **
>
> All SCSI transport protocol standards shall support the CLEAR TASK SET
> task management function.****
>
> ?..****
>
> ** **
>
> ** **
>
> Please feel free to call or send an email to me with any comments or
> questions that you have about this stuff. ****
>
> ** **
>
> Regards, ****
>
> ** **
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose, CA 95138
> Email: mark.evans at wdc.com
> Home office: 541.563.7880
> Cell: 408.391.7805****
>
> ** **
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Gerry
> Houlder
> *Sent:* Tuesday, January 15, 2013 12:11 PM
> *To:* T10 Reflector
> *Subject:* Question about CLEAR TASK SET and ABORT TASK SET****
>
> ** **
>
> I have a question about the effects of the ABORT TASK SET and CLEAR TASK
> SET functions.****
>
> ** **
>
> The scope of these functions is affected by the TST setting (i.e., whether
> the device server maintains a separate task set for each I_T nexus
> (TST=001b) or puts all commands from all I_T nexes in the same task set
> (TST=000b).****
>
> ** **
>
> My historical understanding of these functions is:****
>
>    - ABORT TASK SET is supposed to abort all commands within the defined
>    task set. If TST=000b, this would be all commands from all I_T nexes; if
>    TST=001b, this would be all commands from a particular I_T nexus.****
>    - CLEAR TASK SET is supposed to clear all commands in all task sets,
>    regardless of TST bit setting.****
>
> ** **
>
> The SAM-5 wording regarding these functions seem to describe these
> functions differently.****
>
>    -	The ABORT TASK SET wording seems to require aborting command for a
>    single I_T nexus, which is part of the task set (assuming the device
server
>    has outstanding commands from several I_T nexes) if TST=000b and an
entire
>    task set if TST=001b.****
>
>
>    - SAM-5 wording for CLEAR TASK SET says it only affects one task set,
>    so if TST=000b then it affects all commands and if TST=001b then only
the
>    commands in a single task set (i.e., from one I_T nexus) are affected.*
>    ***
>    - With the current SAM-5 definitions, neither ABORT TASK SET or CLEAR
>    TASK SET will abort all commands in all task sets if TST=0001b. This
seems
>    wrong.****
>
> I think the current SAM-5 wording of these functions is not the best.
> Where do we go from here?****
>
> ** **
>
> ** **
>


From Mark.Evans at wdc.com  Wed Jan 16 09:22:29 2013
From: Mark.Evans at wdc.com (Mark Evans)
Date: Wed, 16 Jan 2013 17:22:29 +0000
Subject: Question about CLEAR TASK SET and ABORT TASK SET
Message-ID: <mailman.28.1441607388.22530.t10@sandbox.t10.org>

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

Hi Gerry,
I was wrong in what I wrote about ABORT TASK SET.  That TMF aborts all
commands received on an I_T nexus.  If TST is set to 001b, this means all
tasks in that particular task set.
Unfortunately, the new definition for CLEAR TASK SET in SAM-2 makes it so
that, when TST is set to 001b, the only way to abort all tasks in all task
sets is by sending a LOGICAL UNIT RESET.  This TMF potentially causes lots of
other stuff to happen besides just aborting all commands in all task sets.
Maybe we should define a new TMF and modify what definitions we have such
that there is a true TMF hierarchy:
1)     ABORT TASK aborts a specific task from a specific I_T nexus;
2)     ABORT I_T NEXUS aborts all tasks from a specific I_T nexus, regardless
of task set;
3)     ABORT TASK SET aborts all tasks in a task set, regardless of I_T
nexus;
4)     CLEAR TASK SET aborts all tasks from all I_T nexuses, regardless of
task set; and
5)     LOGICAL UNIT RESET aborts all tasks from all I_T nexuses, regardless
of task set, and may cause lots of other stuff to happen.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
Home office: 541.563.7880
Cell: 408.391.7805


From gerry.houlder at seagate.com  Wed Jan 16 10:19:41 2013
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Wed, 16 Jan 2013 12:19:41 -0600
Subject: Question about CLEAR TASK SET and ABORT TASK SET
Message-ID: <mailman.29.1441607388.22530.t10@sandbox.t10.org>

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

No we don't need any changes here. As described in current SAM-5 wording,
ABORT TASK SET is already equivalent to an abort I_T nexus function, so
there is no point in adding a new function.
On Wed, Jan 16, 2013 at 11:22 AM, Mark Evans <Mark.Evans at wdc.com> wrote:
>  Hi Gerry,****
>
> ** **
>
> I was wrong in what I wrote about ABORT TASK SET.  That TMF aborts all
> commands received on an I_T nexus.  If TST is set to 001b, this means all
> tasks in that particular task set.****
>
> ** **
>
> Unfortunately, the new definition for CLEAR TASK SET in SAM-2 makes it so
> that, when TST is set to 001b, the only way to abort all tasks in all task
> sets is by sending a LOGICAL UNIT RESET.  This TMF potentially causes lots
> of other stuff to happen besides just aborting all commands in all task
> sets.****
>
> ** **
>
> Maybe we should define a new TMF and modify what definitions we have such
> that there is a true TMF hierarchy:****
>
> ** **
>
> **1)	   **ABORT TASK aborts a specific task from a specific I_T nexus;***
> *
>
> **2)	   **ABORT I_T NEXUS aborts all tasks from a specific I_T nexus,
> regardless of task set;****
>
> **3)	   **ABORT TASK SET aborts all tasks in a task set, regardless of
> I_T nexus;****
>
> **4)	   **CLEAR TASK SET aborts all tasks from all I_T nexuses,
> regardless of task set; and****
>
> **5)	   **LOGICAL UNIT RESET aborts all tasks from all I_T nexuses,
> regardless of task set, and may cause lots of other stuff to happen.****
>
> ** **
>
> Please feel free to call or send an email to me with any comments or
> questions that you have about this stuff. ****
>
> ** **
>
> Regards, ****
>
> ** **
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose, CA 95138
> Email: mark.evans at wdc.com
> Home office: 541.563.7880
> Cell: 408.391.7805****
>
>  ****
>
>  ****
>
> ** **
>


From pooja.gupta at synopsys.com  Fri Jan 18 21:13:20 2013
From: pooja.gupta at synopsys.com (Pooja Gupta)
Date: Sat, 19 Jan 2013 05:13:20 +0000
Subject: FW: Persistent Connection Timeout Timer
Message-ID: <mailman.30.1441607388.22530.t10@sandbox.t10.org>

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

Hi,
I have a concern about Persistent Connection Timeout Timer.
Below is the snippet from Draft  T10/12-251 revision 8:
--------------------- Page# 
37---------------------------------------------------------------------------
--------------------------------------------
6.18.9.3.4 SSP_EM2:Manage
This state:
a) requests the SSP transmitter send EXTEND_CONNECTION; and
b) monitors the receipt of EXTEND_CONNECTION.
Upon entry into this state, this state shall initialize and start the
Transmit Extend Connection timer.
If this state receives:
a) a Frame Transmitted message, then this state shall initialize and start
the Transmit Extend
Connection timer; or
b) a Transmitting Frame message, then this state shall stop the Transmit
Extend Connection timer.
If the Transmit Extend Connection timer expires, then this state shall:
a) send a Transmit EXTEND_CONNECTION message to the SSP transmitter; and
b) after receiving an EXTEND_CONNECTION transmitted message, initialize and
start the Transmit
Extend Connection timer.
--------------------- Page#
37---------------------------------------------------------------------------
--------------------------------------------
So, For the transmission of the EXTEND CONNECTION Primitive, it takes care of
the following:
1.	 Upon entry into SSP_EM2: Manage state, SSP Phy shall initialize and
start the Transmit Extend  Connection timer
2.	 Transmit Extend Connection timer runs when there is nothing to do,
And when timer expires, EXTEND_CONNECTION primitive is transmitted
3.	 If there is a request to transmit a Frame, it stops the timer until
the frame is completely transmitted. It initializes and resumes the timer
upon receipt of Frame Transmitted message.
But it does not take care of the Receiver side of  EXTEND CONNECTION
Primitive. Please see the snippet below:
--------------------- Page# 
37,38------------------------------------------------------------------------
-----------------------------------------------
If this state receives an EXTEND_CONNECTION Received message, then this state
shall initialize and start
the Persistent Connection Timeout timer.
If the Persistent Connection Timeout timer expires, then this state shall
send a Persistent Connection
Established (Disabled) confirmation to the port layer.
--------------------- Page#  37,
38---------------------------------------------------------------------------
--------------------------------------------
Here SSP_EM2:Manage state nowhere accommodates the change in the Persistent
Connection Timeout timer state when receiving the frame.
Consider a situation where the Transmitter has long traffic of Back to Back
Frames to transmit. In that case it will not send the EXTEND_CONNECTION
Primitive(refer to #3 above).
Eventually, the Persistent Connection Timeout Timer will expire and will
force the Receiver to send a Persistent Connection Established (Disabled)
confirmation to the port layer.
So, is it correct, that the Persistent Connection Timeout time keeps on
running, waiting for EXTEND_CONNECTION primitive, even when it is receiving a
Frame?
Please share your opinion on this.
Regards
Pooja


From lohmeyer at t10.org  Sat Jan 19 23:01:32 2013
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 20 Jan 2013 00:01:32 -0700
Subject: Recent T10 documents uploaded since 2013/01/13
Message-ID: <mailman.31.1441607388.22530.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
PQI Letter Ballot Comments Incorporated in PQI-R06
(by: Ie-Wei Njoo)
T10/12-373r6   Uploaded: 2013/01/14   9752829 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-373r6.fdf
PQI Letter Ballot Comments Incorporated in PQI-R06
(by: Ie-Wei Njoo)
T10/12-373r6   Uploaded: 2013/01/14   86737 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-373r6.pdf
PQI Letter Ballot Comments Incorporated in PQI-R06
(by: Ie-Wei Njoo)
T10/12-373r6   Uploaded: 2013/01/14   1205760 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-373r6.xls
SOP PQI Class diagrams for PQI domains
(by: Rob Elliott)
T10/12-426r4   Uploaded: 2013/01/14   211946 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-426r4.pdf
SOP -  Nexus Loss Async Event
(by: Kevin Marks)
T10/13-009r1   Uploaded: 2013/01/14   26251 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-009r1.pdf
Minutes of T10 Plenary Meeting #113 - January 10, 2013
(by: Weber & Lohmeyer)
T10/13-024r0   Uploaded: 2013/01/15   144773 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-024r0.htm
Minutes of T10 Plenary Meeting #113 - January 10, 2013
(by: Weber & Lohmeyer)
T10/13-024r0   Uploaded: 2013/01/15   293429 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-024r0.pdf
Minutes of SAS PHY Working Group - January 8, 2013
(by: Alvin Cox, Bill Voorhees)
T10/13-034r0   Uploaded: 2013/01/14   60806 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-034r0.pdf
Minutes of SOP-PQI Working Group - 9-10 January 2013
(by: Rob Elliott)
T10/13-037r0   Uploaded: 2013/01/14   192861 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-037r0.pdf
Working Drafts
--------------
PCIe(r) architecture Queuing Interface (PQI)
(Editor: Ie-Wei Njoo)
 Rev: 06g      Uploaded: 2013/01/14   2149171 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=pqi-r06g.pdf
SCSI Architecture Model - 5 (SAM-5)
(Editor: George Penokie)
 Rev: 13       Uploaded: 2013/01/16   1421063 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sam5r13.pdf
(Report generated on 2013/01/20 at 00:01:32)
*
* 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  Mon Jan 21 12:41:43 2013
From: George.Penokie at lsi.com (Penokie, George)
Date: Mon, 21 Jan 2013 13:41:43 -0700
Subject: Persistent Connection Timeout Timer
Message-ID: <mailman.32.1441607388.22530.t10@sandbox.t10.org>

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

Pooja,
Yes, you are correct, the Persistent Connection Timeout timer should suspend
during frame receiving traffic. I will write a proposal to fix that.
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at lsi.com
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pooja Gupta
Sent: Friday, January 18, 2013 11:13 PM
To: t10 at t10.org
Subject: FW: Persistent Connection Timeout Timer
Hi,
I have a concern about Persistent Connection Timeout Timer.
Below is the snippet from Draft  T10/12-251 revision 8:
--------------------- Page# 
37---------------------------------------------------------------------------
--------------------------------------------
6.18.9.3.4 SSP_EM2:Manage
This state:
a) requests the SSP transmitter send EXTEND_CONNECTION; and
b) monitors the receipt of EXTEND_CONNECTION.
Upon entry into this state, this state shall initialize and start the
Transmit Extend Connection timer.
If this state receives:
a) a Frame Transmitted message, then this state shall initialize and start
the Transmit Extend
Connection timer; or
b) a Transmitting Frame message, then this state shall stop the Transmit
Extend Connection timer.
If the Transmit Extend Connection timer expires, then this state shall:
a) send a Transmit EXTEND_CONNECTION message to the SSP transmitter; and
b) after receiving an EXTEND_CONNECTION transmitted message, initialize and
start the Transmit
Extend Connection timer.
--------------------- Page#
37---------------------------------------------------------------------------
--------------------------------------------
So, For the transmission of the EXTEND CONNECTION Primitive, it takes care of
the following:
1.	 Upon entry into SSP_EM2: Manage state, SSP Phy shall initialize and
start the Transmit Extend  Connection timer
2.	 Transmit Extend Connection timer runs when there is nothing to do,
And when timer expires, EXTEND_CONNECTION primitive is transmitted
3.	 If there is a request to transmit a Frame, it stops the timer until
the frame is completely transmitted. It initializes and resumes the timer
upon receipt of Frame Transmitted message.
But it does not take care of the Receiver side of  EXTEND CONNECTION
Primitive. Please see the snippet below:
--------------------- Page# 
37,38------------------------------------------------------------------------
-----------------------------------------------
If this state receives an EXTEND_CONNECTION Received message, then this state
shall initialize and start
the Persistent Connection Timeout timer.
If the Persistent Connection Timeout timer expires, then this state shall
send a Persistent Connection
Established (Disabled) confirmation to the port layer.
--------------------- Page#  37,
38---------------------------------------------------------------------------
--------------------------------------------
Here SSP_EM2:Manage state nowhere accommodates the change in the Persistent
Connection Timeout timer state when receiving the frame.
Consider a situation where the Transmitter has long traffic of Back to Back
Frames to transmit. In that case it will not send the EXTEND_CONNECTION
Primitive(refer to #3 above).
Eventually, the Persistent Connection Timeout Timer will expire and will
force the Receiver to send a Persistent Connection Established (Disabled)
confirmation to the port layer.
So, is it correct, that the Persistent Connection Timeout time keeps on
running, waiting for EXTEND_CONNECTION primitive, even when it is receiving a
Frame?
Please share your opinion on this.
Regards
Pooja


From George.Penokie at lsi.com  Mon Jan 21 14:14:21 2013
From: George.Penokie at lsi.com (Penokie, George)
Date: Mon, 21 Jan 2013 15:14:21 -0700
Subject: Persistent Connection Timeout Timer
Message-ID: <mailman.33.1441607388.22530.t10@sandbox.t10.org>

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

Craig,
The Transmit Extend Connection timer is stopped when a frame is transmitting
and is reinitialized and stated after a frame is transmitted. The time is not
suspended, so you do not have to keep track of the value in the timer while
frame are being transmitted.
Adding the same behavior to the Persistent Connection Timeout timer should
not add much complexity.  Too many times I have heard the 'it will never
happen' or 'it will not be a problem' for SAS and too many times it becomes a
problem late in the game causing the need for a much more complex solution to
keep existing products from breaking.
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at lsi.com
From: Craig Stoops [mailto:Craig.Stoops at synopsys.com]
Sent: Monday, January 21, 2013 3:58 PM
To: Penokie, George; Pooja Gupta; t10 at t10.org
Subject: RE: Persistent Connection Timeout Timer
Hi George,
As matter of practicality, the EXTEND_CONNECTION primitive should be receive
apprx 10 times faster than the PCTT, so does it really matter if the PCTT
suspends or not during frame reception? I think that might be an extra
complexity that is not really needed. Also did you mean suspend, or
reinitialize? If you are re-initializing the Transmit side, then I think you
want o reinitialize the receive side too?
Also, on the transmit side, does the Transmit Extend Conenction timer need to
be suspended during frames transmission? Can't we just re-initialize it on
frame transmitted? The EXTEND_CONNECTION has a lower priority to transmit
than a frame, so the transmitter won't send it during a frame even if one is
queued, it will go after the frame.
On the other hand - In order for the scenario cites to happen, there would
have to be 1ms of back to back traffic with not a single gap, which is highly
unlikely. But assuming that this scenario could happen, it is a good reason
why the transmit extend timer maybe shouldn't be stopped or reinitialized on
a frame. Just have it send EXTEND_CONNECTION periodically at 10x the PCTT.
Seems like a fairly simple approach would do, there is no exact timing needed
for the persistent connection to persist.
Trying to reduce the complexity of verification of this.
Craig
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Monday, January 21, 2013 2:42 PM
To: Pooja Gupta; t10 at t10.org
Subject: RE: Persistent Connection Timeout Timer
Pooja,
Yes, you are correct, the Persistent Connection Timeout timer should suspend
during frame receiving traffic. I will write a proposal to fix that.
Bye for now,
George Penokie
LSI Corporation
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at lsi.com
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Pooja Gupta
Sent: Friday, January 18, 2013 11:13 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: FW: Persistent Connection Timeout Timer
Hi,
I have a concern about Persistent Connection Timeout Timer.
Below is the snippet from Draft  T10/12-251 revision 8:
--------------------- Page# 
37---------------------------------------------------------------------------
--------------------------------------------
6.18.9.3.4 SSP_EM2:Manage
This state:
a) requests the SSP transmitter send EXTEND_CONNECTION; and
b) monitors the receipt of EXTEND_CONNECTION.
Upon entry into this state, this state shall initialize and start the
Transmit Extend Connection timer.
If this state receives:
a) a Frame Transmitted message, then this state shall initialize and start
the Transmit Extend
Connection timer; or
b) a Transmitting Frame message, then this state shall stop the Transmit
Extend Connection timer.
If the Transmit Extend Connection timer expires, then this state shall:
a) send a Transmit EXTEND_CONNECTION message to the SSP transmitter; and
b) after receiving an EXTEND_CONNECTION transmitted message, initialize and
start the Transmit
Extend Connection timer.
--------------------- Page#
37---------------------------------------------------------------------------
--------------------------------------------
So, For the transmission of the EXTEND CONNECTION Primitive, it takes care of
the following:
1.	 Upon entry into SSP_EM2: Manage state, SSP Phy shall initialize and
start the Transmit Extend  Connection timer
2.	 Transmit Extend Connection timer runs when there is nothing to do,
And when timer expires, EXTEND_CONNECTION primitive is transmitted
3.	 If there is a request to transmit a Frame, it stops the timer until
the frame is completely transmitted. It initializes and resumes the timer
upon receipt of Frame Transmitted message.
But it does not take care of the Receiver side of  EXTEND CONNECTION
Primitive. Please see the snippet below:
--------------------- Page# 
37,38------------------------------------------------------------------------
-----------------------------------------------
If this state receives an EXTEND_CONNECTION Received message, then this state
shall initialize and start
the Persistent Connection Timeout timer.
If the Persistent Connection Timeout timer expires, then this state shall
send a Persistent Connection
Established (Disabled) confirmation to the port layer.
--------------------- Page#  37,
38---------------------------------------------------------------------------
--------------------------------------------
Here SSP_EM2:Manage state nowhere accommodates the change in the Persistent
Connection Timeout timer state when receiving the frame.
Consider a situation where the Transmitter has long traffic of Back to Back
Frames to transmit. In that case it will not send the EXTEND_CONNECTION
Primitive(refer to #3 above).
Eventually, the Persistent Connection Timeout Timer will expire and will
force the Receiver to send a Persistent Connection Established (Disabled)
confirmation to the port layer.
So, is it correct, that the Persistent Connection Timeout time keeps on
running, waiting for EXTEND_CONNECTION primitive, even when it is receiving a
Frame?
Please share your opinion on this.
Regards
Pooja


From lohmeyer at t10.org  Wed Jan 23 12:55:54 2013
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 23 Jan 2013 13:55:54 -0700
Subject: T10 Reflector clean up
Message-ID: <mailman.34.1441607388.22530.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:
  yigal at lecroy.com
  Dave.Noeldner at lsi.com
  timothy.mcleod at hp.com
  atul at nsysinc.com
  john.lee at ict-lanto.com
  liyy at huaweisymantec.com
  ch79.park at samsung.com
  vinod.bhat at hp.com
  Geert.DeVeirman at maxim-ic.com
  Ope.Aladekomo at microsoft.com
  steven.z.li at intel.com
  maobo1983 at gmail.com
  david.brean at sun.com
  Paul.Ratty at sun.com
  Randall.Ralphs at sun.com
  Akio.Yamazaki at jp.sony.com
  robert at robertrandall.info
  zhouqinglin at huaweisymantec.com
  liuyalun at huaweisymantec.com
  zhzh at huaweisymantec.com
  xushuai at huaweisymantec.com
  Brandon_Awbrey at huaweisymantec.com
  Andrew.Shafranov at amd.com
  rcallan at us.ibm.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 alvin.cox at seagate.com  Thu Jan 24 06:58:26 2013
From: alvin.cox at seagate.com (Alvin Cox)
Date: Thu, 24 Jan 2013 08:58:26 -0600
Subject: No SAS PHY call today 1/24/13
Message-ID: <mailman.35.1441607388.22530.t10@sandbox.t10.org>

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

Sorry for the short cancellation notice. SAS3r05 should be posted tomorrow.
-- 
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809
Office 405-392-3738
E-Mail	alvin.cox at seagate.com


From curtis.stevens at wdc.com  Sat Jan 26 14:57:14 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Sat, 26 Jan 2013 22:57:14 +0000
Subject: [T13] Sad News
Message-ID: <mailman.36.1441607388.22530.t10@sandbox.t10.org>

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

It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.


From curtis.stevens at wdc.com  Sat Jan 26 14:57:14 2013
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Sat, 26 Jan 2013 22:57:14 +0000
Subject: Sad News
Message-ID: <mailman.37.1441607388.22530.t10@sandbox.t10.org>

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

It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.


From jaganr at link-a-media.com  Sat Jan 26 16:25:28 2013
From: jaganr at link-a-media.com (Radhakrishnan Jagannathan)
Date: Sat, 26 Jan 2013 16:25:28 -0800 (PST)
Subject: Sad News
Message-ID: <mailman.38.1441607388.22530.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Radhakrishnan Jagannathan <jaganr at link-a-media.com>
*
My Deep condolence to his family members.
----- Original Message -----
From: "Curtis Stevens" <curtis.stevens at wdc.com>
To: t13 at t13.org, t10 at t10.org
Sent: Saturday, January 26, 2013 2:57:14 PM
Subject: Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013. Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74 
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters. Donations cannot be
made in his name -- but can be made on his behalf. 
------------------------------------------------- 
Curtis E. Stevens 
Director, Standards & Features Technology 
3355 Michelson Dr. #100 
Office: 1-1041 
Irvine, Ca. 92612 
Phone: 949-672-7933 
Cell: 949-307-5050 
E-Mail: Curtis.Stevens at WDC.com 
Remember, you may only be blamed for something if you are actually doing
something. 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Avraham.Shimor at sandisk.com  Sat Jan 26 16:52:57 2013
From: Avraham.Shimor at sandisk.com (Avraham Shimor)
Date: Sun, 27 Jan 2013 00:52:57 +0000
Subject: Sad News
Message-ID: <mailman.39.1441607388.22530.t10@sandbox.t10.org>

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

Please convey my condolence to Marks???s family.
Avraham Shimor
From: owner-t13 at lists.wdc.com [mailto:owner-t13 at lists.wdc.com] On Behalf Of
Curtis Stevens
Sent: Sunday, January 27, 2013 12:57 AM
To: t13 at t13.org; t10 at t10.org
Subject: [T13] Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.
________________________________
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 joel at k-micro.us  Sat Jan 26 19:12:55 2013
From: joel at k-micro.us (Joel Silverman)
Date: Sat, 26 Jan 2013 19:12:55 -0800
Subject: Sad News
Message-ID: <mailman.40.1441607388.22530.t10@sandbox.t10.org>

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

Hi Curtis,
Thanks for letting us know, I share your sadness and will honor the families
wishes for donations to the Salvation army.
Regards,
Joel
________________________________
From: owner-t10 at t10.org on behalf of Curtis Stevens
Sent: Sat 1/26/2013 2:57 PM
To: t13 at t13.org; t10 at t10.org
Subject: Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74 
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com  
Remember, you may only be blamed for something if you are actually doing
something.


From lohmeyer at t10.org  Sat Jan 26 23:01:22 2013
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 27 Jan 2013 00:01:22 -0700
Subject: Recent T10 documents uploaded since 2013/01/20
Message-ID: <mailman.41.1441607388.22530.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPL-3:Clarifications to SP_P_C and SP_P_S State Machines
(by: George Penokie)
T10/13-006r1   Uploaded: 2013/01/23   177446 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-006r1.pdf
Results of Letter Ballot on forwarding SBC-3 to First Public Review
(by: John Lohmeyer)
T10/13-014r0   Uploaded: 2013/01/24   249227 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-014r0.pdf
Results of Letter Ballot on forwarding SBC-3 to First Public Review
(by: John Lohmeyer)
T10/13-014r0   Uploaded: 2013/01/24   445887 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-014r0.txt
NWIP SPL-2
(by: Gary Robinson)
T10/13-048r0   Uploaded: 2013/01/21   52943 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-048r0.pdf
SBC-3 Obsolete SYNC_NV and FUA_NV bits
(by: Rob Elliott)
T10/13-050r0   Uploaded: 2013/01/22   250003 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-050r0.pdf
SBC-3 Eliminate Data-Out for WRITE SAME with UNMAP bit
(by: Rob Elliott)
T10/13-051r0   Uploaded: 2013/01/23   162376 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-051r0.pdf
SBC-3 Close Maximum WRITE SAME Length loophole
(by: Rob Elliott)
T10/13-052r0   Uploaded: 2013/01/23   104725 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-052r0.pdf
Meeting Announcement: T10 Week May 6-10, 2013 -- Bellevue, WA
(by: Mark Overby)
T10/13-053r0   Uploaded: 2013/01/23   12271 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-053r0.pdf
SBC-3 Add Force bit to UNMAP
(by: Rob Elliott)
T10/13-054r0   Uploaded: 2013/01/23   144240 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-054r0.pdf
Working Drafts
--------------
SAS Protocol Layer - 3 (SPL-3)
(Editor: George Penokie)
 Rev: 02       Uploaded: 2013/01/21   9162469 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl3r02.pdf
(Report generated on 2013/01/27 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 ndawal at yahoo.com  Sun Jan 27 01:04:54 2013
From: ndawal at yahoo.com (Nayana Dawalbhakta)
Date: Sun, 27 Jan 2013 01:04:54 -0800 (PST)
Subject: Sad News
Message-ID: <mailman.42.1441607388.22530.t10@sandbox.t10.org>

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

Our deepest condolences to his family. We will keep in mind about Salvation
army donations.
?
Regards.
--- On Sat, 1/26/13, Curtis Stevens <curtis.stevens at wdc.com> wrote:
From: Curtis Stevens <curtis.stevens at wdc.com>
Subject: Sad News
To: "t13 at t13.org" <t13 at t13.org>, "t10 at t10.org" <t10 at t10.org>
Date: Saturday, January 26, 2013, 2:57 PM
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.? Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74 
?
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.?? Donations cannot be
made in his name -- but can be made on his behalf.
?
?
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
?
Remember, you may only be blamed for something if you are actually doing
something.


From m.noblitt at ssi.samsung.com  Sun Jan 27 12:50:57 2013
From: m.noblitt at ssi.samsung.com (Marc Noblitt-SSI)
Date: Sun, 27 Jan 2013 20:50:57 +0000
Subject: Sad News
Message-ID: <mailman.43.1441607388.22530.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Marc Noblitt-SSI <m.noblitt at ssi.samsung.com>
*
Thanks for shearing this Curtis.  It is very sad news indeed.  He will be
missed.
Marc Noblitt | SSD I/O Standards
Samsung Semiconductor, Inc
Cell Phone 408-515-1319
________________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of Curtis Stevens
[curtis.stevens at wdc.com]
Sent: Saturday, January 26, 2013 3:57 PM
To: t13 at t13.org; t10 at t10.org
Subject: Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Mon Jan 28 01:00:00 2013
From: lohmeyer at t10.org (T10 List Manager)
Date: Mon, 28 Jan 2013 02:00:00 -0700
Subject: T10 Reflector Monthly Reminder
Message-ID: <mailman.44.1441607388.22530.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 jaganr at link-a-media.com  Sat Jan 26 16:25:28 2013
From: jaganr at link-a-media.com (Radhakrishnan Jagannathan)
Date: Sun, 27 Jan 2013 00:25:28 +0000
Subject: [T13] Sad News
Message-ID: <mailman.45.1441607388.22530.t10@sandbox.t10.org>

My Deep condolence to his family members.
----- Original Message -----
From: "Curtis Stevens" <curtis.stevens at wdc.com>
To: t13 at t13.org, t10 at t10.org
Sent: Saturday, January 26, 2013 2:57:14 PM
Subject: Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013. Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74 
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters. Donations cannot be
made in his name -- but can be made on his behalf. 
------------------------------------------------- 
Curtis E. Stevens 
Director, Standards & Features Technology 
3355 Michelson Dr. #100 
Office: 1-1041 
Irvine, Ca. 92612 
Phone: 949-672-7933 
Cell: 949-307-5050 
E-Mail: Curtis.Stevens at WDC.com 
Remember, you may only be blamed for something if you are actually doing
something. 


From joel at k-micro.us  Sat Jan 26 19:12:55 2013
From: joel at k-micro.us (Joel Silverman)
Date: Sun, 27 Jan 2013 03:12:55 +0000
Subject: [T13] RE: Sad News
Message-ID: <mailman.46.1441607388.22530.t10@sandbox.t10.org>

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

Hi Curtis,
Thanks for letting us know, I share your sadness and will honor the families
wishes for donations to the Salvation army.
Regards,
Joel
________________________________
From: owner-t10 at t10.org on behalf of Curtis Stevens
Sent: Sat 1/26/2013 2:57 PM
To: t13 at t13.org; t10 at t10.org
Subject: Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.


From rhtcmu at gmail.com  Sun Jan 27 12:20:56 2013
From: rhtcmu at gmail.com (Robert Thibadeau)
Date: Sun, 27 Jan 2013 20:20:56 +0000
Subject: [T13] [T13] Sad News
Message-ID: <mailman.47.1441607388.22530.t10@sandbox.t10.org>

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

Mark was a quality person.  He will be remembered.
On Sat, Jan 26, 2013 at 5:57 PM, Curtis Stevens
<curtis.stevens at wdc.com> wrote:
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933<tel:949-672-7933>
Cell: 949-307-5050<tel:949-307-5050>
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.
--
regards,
Bob Thibadeau
412 370 1245


From Avraham.Shimor at sandisk.com  Sat Jan 26 16:52:57 2013
From: Avraham.Shimor at sandisk.com (Avraham Shimor)
Date: Sun, 27 Jan 2013 00:52:57 +0000
Subject: [T13] RE: Sad News
Message-ID: <mailman.48.1441607388.22530.t10@sandbox.t10.org>

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

Please convey my condolence to Marks???s family.
Avraham Shimor
From: owner-t13 at lists.wdc.com [mailto:owner-t13 at lists.wdc.com] On Behalf Of
Curtis Stevens
Sent: Sunday, January 27, 2013 12:57 AM
To: t13 at t13.org; t10 at t10.org
Subject: [T13] Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.
________________________________
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 ndawal at yahoo.com  Sun Jan 27 01:04:54 2013
From: ndawal at yahoo.com (Nayana Dawalbhakta)
Date: Sun, 27 Jan 2013 09:04:54 +0000
Subject: [T13] Sad News
Message-ID: <mailman.49.1441607388.22530.t10@sandbox.t10.org>

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

Our deepest condolences to his family. We will keep in mind about Salvation
army donations.
Regards.
--- On Sat, 1/26/13, Curtis Stevens <curtis.stevens at wdc.com> wrote:
From: Curtis Stevens <curtis.stevens at wdc.com>
Subject: Sad News
To: "t13 at t13.org" <t13 at t13.org>, "t10 at t10.org" <t10 at t10.org>
Date: Saturday, January 26, 2013, 2:57 PM
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail:
Curtis.Stevens at WDC.com<http://us.mc1817.mail.yahoo.com/mc/compose?to=Curtis.S
tevens at WDC.com>
Remember, you may only be blamed for something if you are actually doing
something.


From m.noblitt at ssi.samsung.com  Sun Jan 27 12:50:57 2013
From: m.noblitt at ssi.samsung.com (Marc Noblitt-SSI)
Date: Sun, 27 Jan 2013 20:50:57 +0000
Subject: [T13] RE: Sad News
Message-ID: <mailman.50.1441607388.22530.t10@sandbox.t10.org>

Thanks for shearing this Curtis.  It is very sad news indeed.  He will be
missed.
Marc Noblitt | SSD I/O Standards
Samsung Semiconductor, Inc
Cell Phone 408-515-1319
________________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of Curtis Stevens
[curtis.stevens at wdc.com]
Sent: Saturday, January 26, 2013 3:57 PM
To: t13 at t13.org; t10 at t10.org
Subject: Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.


From michael.j.selzler at hp.com  Mon Jan 28 08:54:56 2013
From: michael.j.selzler at hp.com (Selzler, Michael)
Date: Mon, 28 Jan 2013 16:54:56 +0000
Subject: [T13] RE: Sad News
Message-ID: <mailman.51.1441607388.22530.t10@sandbox.t10.org>

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

Curtis,
Please send his family our condolences from all of us at HP.
Regards,
Michael Selzler
Mass Storage Engineer - CSBU R&D
Hewlett-Packard Company
(970) 898-1255 | michael.j.selzler at hp.com
3404 East Harmony Road
Fort Collins, CO 80528-9599
USA
From: owner-t13 at lists.wdc.com [mailto:owner-t13 at lists.wdc.com] On Behalf Of
Curtis Stevens
Sent: Saturday, January 26, 2013 3:57 PM
To: t13 at t13.org; t10 at t10.org
Subject: [T13] Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.


From rhtcmu at gmail.com  Sun Jan 27 12:20:56 2013
From: rhtcmu at gmail.com (Robert Thibadeau)
Date: Sun, 27 Jan 2013 15:20:56 -0500
Subject: [T13] Sad News
Message-ID: <mailman.52.1441607388.22530.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Thibadeau <rhtcmu at gmail.com>
*
Mark was a quality person.  He will be remembered.
On Sat, Jan 26, 2013 at 5:57 PM, Curtis Stevens
<curtis.stevens at wdc.com>wrote:
>  It is with great sadness that I have learned that Mark Evans passed away
> on Sunday afternoon 20-Jan-2013.  Please see this link for more
> information:
>
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
> ****
>
> ** **
>
> In lieu of flowers, the family is requesting donations to the Salvation
> Army - either the Waldport, Oregon or San Jose, CA Chapters.	 Donations
> cannot be made in his name -- but can be made on his behalf.****
>
> ** **
>
> ** **
>
> -------------------------------------------------****
>
> Curtis E. Stevens****
>
> Director, Standards & Features Technology****
>
> 3355 Michelson Dr. #100****
>
> Office: 1-1041****
>
> Irvine, Ca. 92612****
>
> Phone: 949-672-7933****
>
> Cell: 949-307-5050****
>
> E-Mail: Curtis.Stevens at WDC.com****
>
> ** **
>
> Remember, you may only be blamed for something if you are actually doing
> something.****
>
> ** **
>
-- 
regards,
Bob Thibadeau
412 370 1245
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From imtiaz.first at samsung.com  Mon Jan 28 15:20:27 2013
From: imtiaz.first at samsung.com (IMTIAZ AHMED)
Date: Mon, 28 Jan 2013 23:20:27 +0000
Subject: [T13] [T13] RE: Sad News
Message-ID: <mailman.53.1441607388.22530.t10@sandbox.t10.org>

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

Dear Curtis,
Thanks for sharing this info. Our deepest condolences to his family members.
Regards,
Imtiaz Ahmed N
Samsung Semiconductors
From: owner-t13 at lists.wdc.com [mailto:owner-t13 at lists.wdc.com] On Behalf Of
Curtis Stevens
Sent: Saturday, January 26, 2013 3:57 PM
To: t13 at t13.org; t10 at t10.org
Subject: [T13] Sad News
It is with great sadness that I have learned that Mark Evans passed away on
Sunday afternoon 20-Jan-2013.  Please see this link for more information:
http://www.newportnewstimes.com/v2_news_articles.php?heading=0&story_id=37510
&page=74
In lieu of flowers, the family is requesting donations to the Salvation Army
- either the Waldport, Oregon or San Jose, CA Chapters.   Donations cannot be
made in his name -- but can be made on his behalf.
-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com
Remember, you may only be blamed for something if you are actually doing
something.
[cid:Z5JE7EUABGFC at namo.co.kr]


From scsi.bbs at lsi.com  Thu Jan 31 21:29:32 2013
From: scsi.bbs at lsi.com (T10 Voting Administrator)
Date: Thu, 31 Jan 2013 22:29:32 -0700
Subject: SAS-3: T10 Letter Ballot T10LBVOTE 13-057r0
Message-ID: <mailman.54.1441607388.22530.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Voting Administrator <scsi.bbs at lsi.com>
*
 2013/01/31 22:28:54
A T10 letter ballot (T10/13-057r0) has just been issued.
If you are a T10 voting member, you should have already received a
separate email with details of how to vote.
If you did not receive this separate email, it is likely that
a spam filter blocked its delivery. You can also find voting
instructions in the Members section of the T10 committee
web site.
The topic of this letter ballot is:
  Forwarding SAS-3 to First Public Review
This ballot closes 2013/03/05 at 12:00 noon MT.
Please do NOT reply to this automated email.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org