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

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPC-5 Add more environment parameters to Temperature log page
(by: Gerald Houlder)
T10/13-253r2   Uploaded: 2014/02/26   139346 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-253r2.pdf
PQI-2 FREEZE OPERATIONAL IQ and UNFREEZE OPERATIONAL IQ functions
(by: Ie-Wei Njoo)
T10/13-287r1   Uploaded: 2014/02/28   202089 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-287r1.pdf
SPL-3 Letter Ballot Comments Resolutions
(by: George Penokie)
T10/13-298r5   Uploaded: 2014/02/26   3150653 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-298r5.fdf
SPL-3 Letter Ballot Comments Resolutions
(by: George Penokie)
T10/13-298r5   Uploaded: 2014/02/26   5561413 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-298r5.pdf
ZBC host aware model clauses for write and read commands
(by: Gerald Houlder)
T10/14-007r6   Uploaded: 2014/02/26   74287 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-007r6.pdf
SAM-5: iSCSI Update
(by: Frederick Knight)
T10/14-016r1   Uploaded: 2014/02/26   192193 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-016r1.pdf
PQI-2 - Interrupt mode and polled mode clarification
(by: Ie-Wei Njoo)
T10/14-026r0   Uploaded: 2014/02/28   177852 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-026r0.pdf
SBC-4 SPC-5 Atomic writes and reads
(by: Elliott, Batwara, Ballard, Martin, Knight)
T10/14-043r2   Uploaded: 2014/02/27   369984 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-043r2.pdf
Minutes of ZBC/CAP Working Group - February 20, 2014
(by: Ralph Weber)
T10/14-060r0   Uploaded: 2014/02/25   33992 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-060r0.htm
SBC-4: 'Not defined' is not defined sufficiently
(by: Ralph Weber)
T10/14-061r0   Uploaded: 2014/02/24   84061 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-061r0.pdf
TE Connectivity patent statement re SAS-3
(by: Driscoll A. Nina)
T10/14-062r0   Uploaded: 2014/02/25   50641 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-062r0.pdf
TE Connectivity Patent Statement and Licensing Declaration
(by: Licensing Counsel; TE Connectivity)
T10/14-063r0   Uploaded: 2014/02/25   65244 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-063r0.pdf
SBC-4 Granular Boundaries for ATOMIC commands
(by: Frederick Knight)
T10/14-064r0   Uploaded: 2014/02/27   159968 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-064r0.pdf
SPC-4 LB: Very Unfriendly VPD Page Hack
(by: Ralph Weber)
T10/14-066r0   Uploaded: 2014/02/26   82045 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-066r0.pdf
Working Drafts
--------------
SCSI Block Commands - 4 (SBC-4)
(Editor: William Martin)
 Rev: 00       Uploaded: 2014/02/28   2801605 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc4r00.pdf
SAS Protocol Layer - 3 (SPL-3)
(Editor: George Penokie)
 Rev: 06f      Uploaded: 2014/02/26   9758736 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl3r06f.pdf
(Report generated on 2014/03/02 at 00:01:56)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gerry.houlder at seagate.com  Mon Mar  3 09:34:25 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Mon, 3 Mar 2014 11:34:25 -0600
Subject: Protection information and power loss/write failures
Message-ID: <mailman.96.1441607400.22532.t10@sandbox.t10.org>

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

Power loss can cause lots of issues, including have a logical block contain
data that is part old data and part new data. If the last part of the
logical block has the "old data", it may also have "old protection
information", so a subsequent read attempt of the new data plus old data
plus old protection information would result in a protection check error.
Most real implementations of storage devices attempt to prevent having a
single logical block have mixed data like this but they are not always
successful. The intent of the standard is that a host should assume any
outstanding write command that did not complete before a power loss occurs
should be retried in its entirety after power is restored.
On Fri, Feb 28, 2014 at 7:20 PM, Vladislav Bolkhovitin <
vbolkhovitin at fusionio.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Vladislav Bolkhovitin <vbolkhovitin at fusionio.com>
> *
> Hello,
>
> In SPC-4 "Write and unmap failures" section says that on power loss for
> those write
> commands, which have not completed when the power loss occurs, data in
> their blocks are
> indeterminate, i.e. can be "old data, new data, vendor-specific data, or
> any
> combination thereof".
>
> Does it mean that protection information tags after a power loss for such
> blocks can
> mismatch their data, so subsequent reads from them can legally return tags
> mismatch errors?
>
> I'm asking, because it is generally assumed that writing a block on an SBC
> device is
> atomic, so the question is if this atomicity assumption applies to the PI
> tags as well?
> Hopefully, not.
>
> The standards are quite ambiguous in this regard, unless I'm missing
> something.
>
> Thanks,
> Vlad
>
>
> This e-mail (and any attachments) is confidential and may be privileged.
>  Any unauthorized use, copying, disclosure or dissemination of this
> communication is prohibited.	If you are not the intended recipient,
>  please notify the sender immediately and delete all copies of the message
> and its attachments.
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>


From mj at feral.com  Mon Mar  3 09:47:58 2014
From: mj at feral.com (Matthew Jacob)
Date: Mon, 3 Mar 2014 09:47:58 -0800
Subject: Protection information and power loss/write failures
Message-ID: <mailman.97.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Matthew Jacob <mj at feral.com>
*
On 3/3/14 9:34 AM, Gerry Houlder wrote:
> Power loss can cause lots of issues, including have a logical block 
> contain data that is part old data and part new data. If the last part 
> of the logical block has the "old data", it may also have "old 
> protection information", so a subsequent read attempt of the new data 
> plus old data plus old protection information would result in a 
> protection check error.
>
> Most real implementations of storage devices attempt to prevent having 
> a single logical block have mixed data like this but they are not 
> always successful. The intent of the standard is that a host should 
> assume any outstanding write command that did not complete before a 
> power loss occurs should be retried in its entirety after power is 
> restored.
>
Note that recovery mechanisms, if any, are device specific. Devices that 
can safely retry can be retried. Devices that cannot, e.g., tape or 
optical media (in some cases) cannot.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Mon Mar  3 15:52:30 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 03 Mar 2014 16:52:30 -0700
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
  opcode
Message-ID: <mailman.98.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
I have added an agenda item to the CAP working group to consider what should
be done about an inconsistency between the READ (12) operation code in:
  Standard READ (12)
	   opcode
  MMC-4    28h
  MMC-5    A8h
  MMC-6    A8h
I would welcome opinions on how we should address this issue. Z JAN from
China says MMC-4 is correct and the other standards are in error.
John
--
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 Ralph.Weber at wdc.com  Mon Mar  3 17:16:01 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Tue, 4 Mar 2014 01:16:01 +0000
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
  opcode
Message-ID: <mailman.99.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <Ralph.Weber at wdc.com>
*
As described below, MMC-4 is violating an operation code requirement that has
been documented since SCSI-2 (see 7.2.1 in SCSI-2 r10L).
o Operation codes 2xh and 3xh are in operation code group 1 (i.e., 10 byte
CDBs).
o Group 5 is the correct choice for a 12 byte CDB (i.e., operation codes Axh
and Bxh).
I would further note that the READ(12) operation code in SBC is A8h, and the
the numeric operation codes list in SPC cites MMC-6 as having an optional
READ(12) command defined with operation code A8h.
It appears to me that MMC-4 had in incorrect operation code definition for
READ(12), which was corrected in MMC-5.
All the best,
.Ralph
________________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of John Lohmeyer
[lohmeyer at t10.org]
Sent: Monday, March 03, 2014 5:52 PM
To: T10 Reflector
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)  opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
I have added an agenda item to the CAP working group to consider what should
be done about an inconsistency between the READ (12) operation code in:
  Standard READ (12)
	   opcode
  MMC-4    28h
  MMC-5    A8h
  MMC-6    A8h
I would welcome opinions on how we should address this issue. Z JAN from
China says MMC-4 is correct and the other standards are in error.
John
--
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
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From takeshi_kohda at post.pioneer.co.jp  Mon Mar  3 17:34:17 2014
From: takeshi_kohda at post.pioneer.co.jp (takeshi_kohda at post.pioneer.co.jp)
Date: Tue, 4 Mar 2014 10:34:17 +0900
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)  opcode
Message-ID: <mailman.100.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <takeshi_kohda at post.pioneer.co.jp>
*
Hi,
I think opcode 28h is assigned for READ(10), and not for READ(12) from the
beginning of MMC-1.
SBC rev.8c section 6.1 Table 1 defines opcode for READ(12) as A8h.
MMC-1 rev.10a refers SBC standards and in section B.3 Table B.1 also defines
opcode for READ(12) as A8h.
Basically this definition is not changed through MMC history.
At least, MMC-4 rev05a draft also defines READ(12) as A8h in section 6.20.
If final release of MMC-4 defines 28h for READ(12), it should be a mistake.
best regards,
---
Takeshi Kohda
owner-t10 at t10.org wrote on 2014/03/04 08:52:30:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * John Lohmeyer <lohmeyer at t10.org>
> *
> I have added an agenda item to the CAP working group to consider
> what should be done about an inconsistency between the READ (12)
> operation code in:
>
>   Standard READ (12)
>	     opcode
>   MMC-4    28h
>   MMC-5    A8h
>   MMC-6    A8h
>
> I would welcome opinions on how we should address this issue. Z JAN
> from China says MMC-4 is correct and the other standards are in error.
>
> John
>
>
> --
> 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
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Mon Mar  3 17:55:44 2014
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 4 Mar 2014 10:55:44 +0900
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12) opcode
Message-ID: <mailman.101.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <keiji_katata at post.pioneer.co.jp>
*
Hello Ralph,
The MMC-4 draft document that I have is "mmc4r05a.pdf".
It is "WORKING DRAFT T10/1545-D Revision 5a 3 May 2004".
I cannot find any sentence/table that says "Ope code of READ(12) is 28h".
Could you tell me what page is wrong.
Best regards,
Keiji Katata
PIONEER CORP.
Ralph Weber <Ralph.Weber at wdc.com>@t10.org on 2014/03/04 10:16:01
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B: T10 Reflector <t10 at t10.org>
cc:    (bcc: Keiji Katata/Pioneer)
$B7oL>(B: RE: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12) 
opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <Ralph.Weber at wdc.com>
*
As described below, MMC-4 is violating an operation code requirement that has
been documented since SCSI-2 (see 7.2.1 in SCSI-2 r10L).
o Operation codes 2xh and 3xh are in operation code group 1 (i.e., 10 byte
CDBs).
o Group 5 is the correct choice for a 12 byte CDB (i.e., operation codes Axh
and
Bxh).
I would further note that the READ(12) operation code in SBC is A8h, and the
the
numeric operation codes list in SPC cites MMC-6 as having an optional
READ(12)
command defined with operation code A8h.
It appears to me that MMC-4 had in incorrect operation code definition for
READ(12), which was corrected in MMC-5.
All the best,
.Ralph
________________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of John Lohmeyer
[lohmeyer at t10.org]
Sent: Monday, March 03, 2014 5:52 PM
To: T10 Reflector
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)  opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
I have added an agenda item to the CAP working group to consider what should
be
done about an inconsistency between the READ (12) operation code in:
  Standard READ (12)
	   opcode
  MMC-4    28h
  MMC-5    A8h
  MMC-6    A8h
I would welcome opinions on how we should address this issue. Z JAN from
China
says MMC-4 is correct and the other standards are in error.
John
--
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
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Ralph.Weber at wdc.com  Mon Mar  3 18:02:08 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Tue, 4 Mar 2014 02:02:08 +0000
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
 opcode
Message-ID: <mailman.102.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <Ralph.Weber at wdc.com>
*
I concur with everything Katatasan has stated in both his postings to the T10
reflector.
The PDF files posted on T10.org do not show any case where the Public Review
version of MMC-4 specified 28h as the operation code for READ(12).  ...
READ(10) is 28h not READ(12), and that is what MMC-4 r05a says.
All the best,
.Ralph
________________________________________
From: keiji_katata at post.pioneer.co.jp [keiji_katata at post.pioneer.co.jp]
Sent: Monday, March 03, 2014 7:55 PM
To: Ralph Weber
Cc: T10 Reflector
Subject: RE: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
opcode
Hello Ralph,
The MMC-4 draft document that I have is "mmc4r05a.pdf".
It is "WORKING DRAFT T10/1545-D Revision 5a 3 May 2004".
I cannot find any sentence/table that says "Ope code of READ(12) is 28h".
Could you tell me what page is wrong.
Best regards,
Keiji Katata
PIONEER CORP.
Ralph Weber <Ralph.Weber at wdc.com>@t10.org on 2014/03/04 10:16:01
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B: T10 Reflector <t10 at t10.org>
cc:    (bcc: Keiji Katata/Pioneer)
$B7oL>(B: RE: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12) 
opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <Ralph.Weber at wdc.com>
*
As described below, MMC-4 is violating an operation code requirement that has
been documented since SCSI-2 (see 7.2.1 in SCSI-2 r10L).
o Operation codes 2xh and 3xh are in operation code group 1 (i.e., 10 byte
CDBs).
o Group 5 is the correct choice for a 12 byte CDB (i.e., operation codes Axh
and
Bxh).
I would further note that the READ(12) operation code in SBC is A8h, and the
the
numeric operation codes list in SPC cites MMC-6 as having an optional
READ(12)
command defined with operation code A8h.
It appears to me that MMC-4 had in incorrect operation code definition for
READ(12), which was corrected in MMC-5.
All the best,
.Ralph
________________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of John Lohmeyer
[lohmeyer at t10.org]
Sent: Monday, March 03, 2014 5:52 PM
To: T10 Reflector
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)  opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
I have added an agenda item to the CAP working group to consider what should
be
done about an inconsistency between the READ (12) operation code in:
  Standard READ (12)
	   opcode
  MMC-4    28h
  MMC-5    A8h
  MMC-6    A8h
I would welcome opinions on how we should address this issue. Z JAN from
China
says MMC-4 is correct and the other standards are in error.
John
--
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
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From jgeldman at micron.com  Mon Mar  3 18:23:42 2014
From: jgeldman at micron.com (John Geldman (jgeldman))
Date: Tue, 4 Mar 2014 02:23:42 +0000
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
 opcode
Message-ID: <mailman.103.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "John Geldman (jgeldman)" <jgeldman at micron.com>
*
I suggest you search for Read(12). The command description and annexes all
seem to agree on A8h.
Regards,
John Geldman
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
keiji_katata at post.pioneer.co.jp
Sent: Monday, March 03, 2014 5:56 PM
To: Ralph Weber
Cc: T10 Reflector
Subject: RE: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* <keiji_katata at post.pioneer.co.jp>
*
Hello Ralph,
The MMC-4 draft document that I have is "mmc4r05a.pdf".
It is "WORKING DRAFT T10/1545-D Revision 5a 3 May 2004".
I cannot find any sentence/table that says "Ope code of READ(12) is 28h".
Could you tell me what page is wrong.
Best regards,
Keiji Katata
PIONEER CORP.
Ralph Weber <Ralph.Weber at wdc.com>@t10.org on 2014/03/04 10:16:01
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B: T10 Reflector <t10 at t10.org>
cc:    (bcc: Keiji Katata/Pioneer)
$B7oL>(B: RE: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12) 
opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <Ralph.Weber at wdc.com>
*
As described below, MMC-4 is violating an operation code requirement that has
been documented since SCSI-2 (see 7.2.1 in SCSI-2 r10L).
o Operation codes 2xh and 3xh are in operation code group 1 (i.e., 10 byte
CDBs).
o Group 5 is the correct choice for a 12 byte CDB (i.e., operation codes Axh
and Bxh).
I would further note that the READ(12) operation code in SBC is A8h, and the
the numeric operation codes list in SPC cites MMC-6 as having an optional
READ(12) command defined with operation code A8h.
It appears to me that MMC-4 had in incorrect operation code definition for
READ(12), which was corrected in MMC-5.
All the best,
.Ralph
________________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of John Lohmeyer
[lohmeyer at t10.org]
Sent: Monday, March 03, 2014 5:52 PM
To: T10 Reflector
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)  opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
I have added an agenda item to the CAP working group to consider what should
be done about an inconsistency between the READ (12) operation code in:
  Standard READ (12)
	   opcode
  MMC-4    28h
  MMC-5    A8h
  MMC-6    A8h
I would welcome opinions on how we should address this issue. Z JAN from
China says MMC-4 is correct and the other standards are in error.
John
--
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
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From jgeldman at micron.com  Mon Mar  3 18:37:03 2014
From: jgeldman at micron.com (John Geldman (jgeldman))
Date: Tue, 4 Mar 2014 02:37:03 +0000
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
 opcode
Message-ID: <mailman.104.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "John Geldman (jgeldman)" <jgeldman at micron.com>
*
My apologies, I forgot the space between the 'd' and '('. 
Look for: Read (12)
For example see Table 335.
Regards,
John Geldman
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of John Geldman
(jgeldman)
Sent: Monday, March 03, 2014 6:24 PM
To: keiji_katata at post.pioneer.co.jp; Ralph Weber
Cc: T10 Reflector
Subject: RE: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* "John Geldman (jgeldman)" <jgeldman at micron.com>
*
I suggest you search for Read(12). The command description and annexes all
seem to agree on A8h.
Regards,
John Geldman
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
keiji_katata at post.pioneer.co.jp
Sent: Monday, March 03, 2014 5:56 PM
To: Ralph Weber
Cc: T10 Reflector
Subject: RE: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* <keiji_katata at post.pioneer.co.jp>
*
Hello Ralph,
The MMC-4 draft document that I have is "mmc4r05a.pdf".
It is "WORKING DRAFT T10/1545-D Revision 5a 3 May 2004".
I cannot find any sentence/table that says "Ope code of READ(12) is 28h".
Could you tell me what page is wrong.
Best regards,
Keiji Katata
PIONEER CORP.
Ralph Weber <Ralph.Weber at wdc.com>@t10.org on 2014/03/04 10:16:01
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B: T10 Reflector <t10 at t10.org>
cc:    (bcc: Keiji Katata/Pioneer)
$B7oL>(B: RE: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12) 
opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <Ralph.Weber at wdc.com>
*
As described below, MMC-4 is violating an operation code requirement that has
been documented since SCSI-2 (see 7.2.1 in SCSI-2 r10L).
o Operation codes 2xh and 3xh are in operation code group 1 (i.e., 10 byte
CDBs).
o Group 5 is the correct choice for a 12 byte CDB (i.e., operation codes Axh
and Bxh).
I would further note that the READ(12) operation code in SBC is A8h, and the
the numeric operation codes list in SPC cites MMC-6 as having an optional
READ(12) command defined with operation code A8h.
It appears to me that MMC-4 had in incorrect operation code definition for
READ(12), which was corrected in MMC-5.
All the best,
.Ralph
________________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of John Lohmeyer
[lohmeyer at t10.org]
Sent: Monday, March 03, 2014 5:52 PM
To: T10 Reflector
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)  opcode
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
I have added an agenda item to the CAP working group to consider what should
be done about an inconsistency between the READ (12) operation code in:
  Standard READ (12)
	   opcode
  MMC-4    28h
  MMC-5    A8h
  MMC-6    A8h
I would welcome opinions on how we should address this issue. Z JAN from
China says MMC-4 is correct and the other standards are in error.
John
--
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
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From curtis.ballard at hp.com  Tue Mar  4 09:37:19 2014
From: curtis.ballard at hp.com (Ballard, Curtis C (HP Storage))
Date: Tue, 4 Mar 2014 17:37:19 +0000
Subject: Latest microcode activation updates version posted
Message-ID: <mailman.105.1441607400.22532.t10@sandbox.t10.org>

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

It is a bit late going up but the latest version of the microcode activation
updates proposal is now available on the T10 web site:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-267r2.pdf
Most of the wording is what we discussed in January but it has moved due to
the request that I investigate breaking the activation material into a
separate sub-clause.  A bit of text had to be modified to make a clean split.
After drafting a version with activation split from download I felt the
presentation was cleaner and easier to understand so I have updated the
proposal to split that material and have tried to make it easy to
differentiate moved text from new text.  Splitting the material drug in some
new text but not much real content, mostly updated cross references.
Curtis Ballard
Software Architect
HP Storage
Hewlett-Packard Company
+1 970 898 3013 / Tel
Curtis.Ballard at hp.com / Email
3404 E. Harmony Rd.
Fort Collins, CO 80528
USA


From lohmeyer at t10.org  Tue Mar  4 09:22:55 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 04 Mar 2014 10:22:55 -0700
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
  opcode
Message-ID: <mailman.106.1441607400.22532.t10@sandbox.t10.org>

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

Sorry everyone. I accidentally reversed the opcode values in my first posting
|from what Z JAN said. The exact words in the email to me were:
>In [ mmc6r02g.pdf 6.15 ] and [ mmc5r04.pdf 6.16 ], the OperationCode of
READ(12) command had error value of 28h, but it should be A8h. 
>
>The value in mmc4r05a.pdf is right.
For reference:
The final working draft of MMC-4:
  http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc4r05a.pdf
PDF Page 334, Table 335 - READ (12) CDB has operation code (A8h)
The final working draft of MMC-5:
  http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc5r04.pdf
PDF Page 428, Table 347 - READ (12) CDB has operation code (28h)
The final working draft of MMC-6:
  http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc6r02g.pdf
PDF Page 400, Table 336 - READ (12) CDB has operation code (28h)
I think that Z JAN is correct and both MMC-5 and MMC-6 are in error.
By the way, only T10 members will be able to access the above links to the
final working drafts of the MMC standards.
John
--
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 bill.martin at ssi.samsung.com  Tue Mar  4 10:36:47 2014
From: bill.martin at ssi.samsung.com (Bill Martin-SSI)
Date: Tue, 4 Mar 2014 18:36:47 +0000
Subject: SBC-4 r0
Message-ID: <mailman.107.1441607400.22532.t10@sandbox.t10.org>

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

For all of those who are interested in SBC-4, the first revision (r0) is
posted. This revision is equivalent to the ANSI version with a couple of the
edits that they made corrected back to the original wording in SBC-3r36. I
will roll a new revision with approved proposals following next week's T10
meeting.
Bill Martin
SSD I/O Standards
Samsung Semiconductor, Inc.
Cell (408) 499-1839


From Ralph.Weber at wdc.com  Tue Mar  4 10:50:46 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Tue, 4 Mar 2014 18:50:46 +0000
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
  opcode
Message-ID: <mailman.108.1441607400.22532.t10@sandbox.t10.org>

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

Depending on where one looks, MMC-6 r02g associates READ (12) with three
different op codes.
  *   28h once
  *   A8h ~7 times
  *   AAh ~ twice
There is also at least one Aah as the WRITE (12) op code.
Pity the poor soul sent to drain this swamp.
All the best,
.Ralph
________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of John Lohmeyer
[lohmeyer at t10.org]
Sent: Tuesday, March 04, 2014 11:22 AM
To: T10 Reflector
Subject: Re: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
opcode
Sorry everyone. I accidentally reversed the opcode values in my first posting
|from what Z JAN said. The exact words in the email to me were:
In [ mmc6r02g.pdf 6.15 ] and [ mmc5r04.pdf 6.16 ], the OperationCode of
READ(12) command had error value of 28h, but it should be A8h.
The value in mmc4r05a.pdf is right.
For reference:
The final working draft of MMC-4:
  http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc4r05a.pdf
PDF Page 334, Table 335 - READ (12) CDB has operation code (A8h)
The final working draft of MMC-5:
  http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc5r04.pdf
PDF Page 428, Table 347 - READ (12) CDB has operation code (28h)
The final working draft of MMC-6:
  http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc6r02g.pdf
PDF Page 400, Table 336 - READ (12) CDB has operation code (28h)
I think that Z JAN is correct and both MMC-5 and MMC-6 are in error.
By the way, only T10 members will be able to access the above links to the
final working drafts of the MMC standards.
John
--
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 Ralph.Weber at wdc.com  Tue Mar  4 20:18:18 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Wed, 5 Mar 2014 04:18:18 +0000
Subject: Penultimate CAP review of the SPC-4 Letter Ballot
Message-ID: <mailman.109.1441607400.22532.t10@sandbox.t10.org>

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

The usual SPC-4 Letter Ballot cast of Acrobat brigands has been uploaded (see
below for the pro forma details).
This announcement differs from all preceding instances in one seriously
significant way. A very very small number of Letter Ballot comments remain to
be closed, and when that is done, the time will have come to forward SPC-4 to
Public Review.
The 15 open comments can be summarized as follows.
3 - Pending incorporation:
  *   1 - Remove revision history [LSI-4]
  *   1 - Ensure Numeric Codes Annex is up to date (esp. op codes) [HP-3070]
  *   1 - IANA linkage for iSCSI version descriptors [EMC-3008]
4 - Waiting for action on proposals:
  *   2 - Waiting for SAM-5 proposals 14-050 and 14-051 to be approved w/ no
SPC-4 mods [HP-283, HP-285]
  *   1 - SPC-4 mod is waiting for SAM-5 proposal 14-050 to be approved
[HP-281]
  *   1 - Waiting for approval of SPC-4, SAM-5 Multi-LUN microcode download
updates (13-267) [Ballard] [Micron-3001]
8 - Flagged for March CAP discussion (see page 5 of 13-256r6 for details)
I expect the New Orleans CAP working group to apply as much time as may be
needed to close these 15 comments. If everybody is on their best behavior,
this work could take as little as four hours (consider this estimate to now
be appropriately jinxed).
A trio of recent developments in SPC-4 r36r may be of interest to the more
intense reviewers.
  *   For consistency with the way 12-404r1 reformatted its new row in table
211 (Persistent Reservations Allowed Commands field values), all the other
rows of table 211 were reformatted to the new "standard". This is not
believed to have resulted in any substantive changes, but ... your mileage
may vary.
  *   The Glossary was reformatted into the latest ISO style, which means a
very large number of "notes to entry" now appear in place of semi-colons and
other mind-altering hacks.
  *   An ISO Style Bibliography was added ... and populated with
not-precisely-normative items previously found amongst the Normative
References. Complaints about the editor's ham-handed work are not uncommon is
cases such as this.
The all to familiar litany of Letter Ballot files follows.
The human-readable (+/- 10%) SPC-4 Letter Ballot comments database:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r6.pdf
The (amazingly short) supplement to the SPC-4 Letter Ballot comments
database:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-070r8.pdf
The SPC-4 revision that reflects all the worthy changes described in the
above two documents:
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36r.pdf
The Acrobat readable (barely) SPC-4 Letter Ballot comments database:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r6.fdf
See you next week,
.Ralph


From Frederick.Knight at netapp.com  Wed Mar  5 05:48:22 2014
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Wed, 5 Mar 2014 13:48:22 +0000
Subject: Minor wording error in SPC-4r36r
Message-ID: <mailman.110.1441607400.22532.t10@sandbox.t10.org>

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

5.5.2 Retrieving error history with the READ BUFFER command
Device servers may allow the error history to be retrieved using a sequence
of READ BUFFER commands on
one I_T nexus.
Error history is returned using error history snapshots. An error history
snapshot is the contents of the error
history at a specific point in time, created by the device server at vendor
specific times or requested by the
application client using the READ BUFFER command with certain buffer IDs.
The I_T nexus being used to retrieve error history snapshot is called the
error history I_T nexus. Only one I_T
nexus is allowed to be the error history I_T nexus, and only the error
history I_T nexus to retrieve an error
history snapshot at a time.
 ----------------------------------------------------------------
The end of that last doesn't make grammatical sense.
and only the error history I_T nexus is allowed to retrieve an error history
snapshot at a time.
and only the error history I_T nexus is allowed to retrieve an error history
shapshots only one at a time.
and only the error history I_T nexus is allowed to retrieve only one error
history snapshot at a time.
NOT sure which it should be, but something is broken in that sentence.
		Fred Knight


From gerry.houlder at seagate.com  Wed Mar  5 07:04:20 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Wed, 5 Mar 2014 09:04:20 -0600
Subject: Minor wording error in SPC-4r36r
Message-ID: <mailman.111.1441607400.22532.t10@sandbox.t10.org>

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

I agree rewording is needed. How about this:
The I_T nexus being used to retrieve an error history snapshot is called
the error history I_T nexus. Only one I_T nexus at a time is allowed to be
the error history I_T nexus.
On Wed, Mar 5, 2014 at 7:48 AM, Knight, Frederick <
Frederick.Knight at netapp.com> wrote:
>  *5.5.2 Retrieving error history with the READ BUFFER command*
>
>
>
> Device servers may allow the error history to be retrieved using a
> sequence of READ BUFFER commands on
>
> one I_T nexus.
>
>
>
> Error history is returned using error history snapshots. An error history
> snapshot is the contents of the error
>
> history at a specific point in time, created by the device server at
> vendor specific times or requested by the
>
> application client using the READ BUFFER command with certain buffer IDs.
>
>
>
> The I_T nexus being used to retrieve error history snapshot is called the
> error history I_T nexus. Only one I_T
>
> nexus is allowed to be the error history I_T nexus, and only the error
> history I_T nexus to retrieve an error
>
> history snapshot at a time.
>
>
>
>  ----------------------------------------------------------------
>
>
>
> The end of that last doesn't make grammatical sense.
>
>
>
> and only the error history I_T nexus is allowed to retrieve an error
> history snapshot at a time.
>
>
>
> and only the error history I_T nexus is allowed to retrieve an error
> history shapshots only one at a time.
>
>
>
> and only the error history I_T nexus is allowed to retrieve only one error
> history snapshot at a time.
>
>
>
> NOT sure which it should be, but something is broken in that sentence.
>
>
>
>		  Fred Knight
>


From bill.martin at ssi.samsung.com  Wed Mar  5 09:27:02 2014
From: bill.martin at ssi.samsung.com (Bill Martin-SSI)
Date: Wed, 5 Mar 2014 17:27:02 +0000
Subject: Minor wording error in SPC-4r36r
Message-ID: <mailman.112.1441607400.22532.t10@sandbox.t10.org>

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

I think Gerry is on the right track, but the end of the sentence needs to be
retained and needs to state:
and only the error history I_T nexus is allowed to retrieve an error history
snapshot
Bill Martin
SSD I/O Standards
Samsung Semiconductor, Inc.
Cell (408) 499-1839
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Wednesday, March 05, 2014 7:04 AM
To: T10 Reflector
Subject: Re: Minor wording error in SPC-4r36r
I agree rewording is needed. How about this:
The I_T nexus being used to retrieve an error history snapshot is called the
error history I_T nexus. Only one I_T nexus at a time is allowed to be the
error history I_T nexus.
On Wed, Mar 5, 2014 at 7:48 AM, Knight, Frederick
<Frederick.Knight at netapp.com> wrote:
5.5.2 Retrieving error history with the READ BUFFER command
Device servers may allow the error history to be retrieved using a sequence
of READ BUFFER commands on
one I_T nexus.
Error history is returned using error history snapshots. An error history
snapshot is the contents of the error
history at a specific point in time, created by the device server at vendor
specific times or requested by the
application client using the READ BUFFER command with certain buffer IDs.
The I_T nexus being used to retrieve error history snapshot is called the
error history I_T nexus. Only one I_T
nexus is allowed to be the error history I_T nexus, and only the error
history I_T nexus to retrieve an error
history snapshot at a time.
 ----------------------------------------------------------------
The end of that last doesn't make grammatical sense.
and only the error history I_T nexus is allowed to retrieve an error history
snapshot at a time.
and only the error history I_T nexus is allowed to retrieve an error history
shapshots only one at a time.
and only the error history I_T nexus is allowed to retrieve only one error
history snapshot at a time.
NOT sure which it should be, but something is broken in that sentence.
		Fred Knight


From kdbutt at us.ibm.com  Wed Mar  5 10:48:49 2014
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 5 Mar 2014 11:48:49 -0700
Subject: Minor wording error in SPC-4r36r
Message-ID: <mailman.113.1441607400.22532.t10@sandbox.t10.org>

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

I like Gerry's wording better.
Kevin D. Butt
SCSI Architect, Tape Firmware, T10 Standards
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:	Gerry Houlder <gerry.houlder at seagate.com>
To:	T10 Reflector <t10 at t10.org>, 
Date:	03/05/2014 09:33 AM
Subject:	Re: Minor wording error in SPC-4r36r
Sent by:	owner-t10 at t10.org
I agree rewording is needed. How about this:
The I_T nexus being used to retrieve an error history snapshot is called 
the error history I_T nexus. Only one I_T nexus at a time is allowed to be 
the error history I_T nexus.
On Wed, Mar 5, 2014 at 7:48 AM, Knight, Frederick <
Frederick.Knight at netapp.com> wrote:
5.5.2 Retrieving error history with the READ BUFFER command
Device servers may allow the error history to be retrieved using a 
sequence of READ BUFFER commands on
one I_T nexus.
Error history is returned using error history snapshots. An error history 
snapshot is the contents of the error
history at a specific point in time, created by the device server at 
vendor specific times or requested by the
application client using the READ BUFFER command with certain buffer IDs.
The I_T nexus being used to retrieve error history snapshot is called the 
error history I_T nexus. Only one I_T
nexus is allowed to be the error history I_T nexus, and only the error 
history I_T nexus to retrieve an error
history snapshot at a time.
 ----------------------------------------------------------------
The end of that last doesn?t make grammatical sense.
and only the error history I_T nexus is allowed to retrieve an error 
history snapshot at a time.
and only the error history I_T nexus is allowed to retrieve an error 
history shapshots only one at a time.
and only the error history I_T nexus is allowed to retrieve only one error 
history snapshot at a time.
NOT sure which it should be, but something is broken in that sentence.
		Fred Knight


From kdbutt at us.ibm.com  Wed Mar  5 10:47:32 2014
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 5 Mar 2014 11:47:32 -0700
Subject: Minor wording error in SPC-4r36r
Message-ID: <mailman.114.1441607400.22532.t10@sandbox.t10.org>

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

The intent is:
and only the error history I_T nexus is allowed to retrieve an error 
history snapshot at a time.
Kevin D. Butt
SCSI Architect, Tape Firmware, T10 Standards
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:	"t10 at t10.org" <t10 at t10.org>, 
Date:	03/05/2014 07:14 AM
Subject:	Minor wording error in SPC-4r36r
Sent by:	owner-t10 at t10.org
5.5.2 Retrieving error history with the READ BUFFER command
Device servers may allow the error history to be retrieved using a 
sequence of READ BUFFER commands on
one I_T nexus.
Error history is returned using error history snapshots. An error history 
snapshot is the contents of the error
history at a specific point in time, created by the device server at 
vendor specific times or requested by the
application client using the READ BUFFER command with certain buffer IDs.
The I_T nexus being used to retrieve error history snapshot is called the 
error history I_T nexus. Only one I_T
nexus is allowed to be the error history I_T nexus, and only the error 
history I_T nexus to retrieve an error
history snapshot at a time.
 ----------------------------------------------------------------
The end of that last doesn?t make grammatical sense.
and only the error history I_T nexus is allowed to retrieve an error 
history snapshot at a time.
and only the error history I_T nexus is allowed to retrieve an error 
history shapshots only one at a time.
and only the error history I_T nexus is allowed to retrieve only one error 
history snapshot at a time.
NOT sure which it should be, but something is broken in that sentence.
		Fred Knight


From keiji_katata at post.pioneer.co.jp  Wed Mar  5 17:54:27 2014
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 6 Mar 2014 10:54:27 +0900
Subject: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12) opcode
Message-ID: <mailman.115.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <keiji_katata at post.pioneer.co.jp>
*
Thank you John and Ralph,
It is difficult to make a comment for this.
We checked line by line many times and checked consistency between MMC draft
slandered and Fuji specification.
I really checked any paragraphs.
But...
Best regards,
Keiji Katata
PIONEER CORP.
Ralph Weber <Ralph.Weber at wdc.com>@t10.org on 2014/03/05 03:50:46
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B: T10 Reflector <t10 at t10.org>
cc:
$B7oL>(B: RE: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12) 
opcode
Depending on where one looks, MMC-6 r02g associates READ (12) with three
different op codes.
28h once
A8h ~7 times
AAh ~ twice
There is also at least one Aah as the WRITE (12) op code.
Pity the poor soul sent to drain this swamp.
All the best,
.Ralph
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of John Lohmeyer
[lohmeyer at t10.org]
Sent: Tuesday, March 04, 2014 11:22 AM
To: T10 Reflector
Subject: Re: Inconsistency between MMC-4, MMC-5, and MMC-6 on READ (12)
opcode
Sorry everyone. I accidentally reversed the opcode values in my first posting
|from what Z JAN said. The exact words in the email to me were:
In [ mmc6r02g.pdf 6.15 ] and [ mmc5r04.pdf 6.16 ], the OperationCode of
READ(12)
command had error value of 28h, but it should be A8h.
The value in mmc4r05a.pdf is right.
For reference:
The final working draft of MMC-4:
  http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc4r05a.pdf
PDF Page 334, Table 335 - READ (12) CDB has operation code (A8h)
The final working draft of MMC-5:
  http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc5r04.pdf
PDF Page 428, Table 347 - READ (12) CDB has operation code (28h)
The final working draft of MMC-6:
  http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc6r02g.pdf
PDF Page 400, Table 336 - READ (12) CDB has operation code (28h)
I think that Z JAN is correct and both MMC-5 and MMC-6 are in error.
By the way, only T10 members will be able to access the above links to the
final
working drafts of the MMC standards.
John
--
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 Ralph.Weber at wdc.com  Wed Mar  5 18:21:25 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Thu, 6 Mar 2014 02:21:25 +0000
Subject: SBC-4: WRITE ZEROS command definition uploaded
Message-ID: <mailman.116.1441607400.22532.t10@sandbox.t10.org>

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

The biggest vat of Kool Aid which could be found has not been sufficient to
stop the gnashing of teeth over the Force Unmap concept amongst HDD engineers
for whom totally virtualized LBA interfaces are a non sequitur.
Based on the complaints heard around the Irvine water coolers, an attempt to
find some middle ground in the form of a proposal for a new command has been
uploaded. The notion is to graft the stems from a WRITE SAME command onto the
roots from an UNMAP command.
In classic standardeze style, the result should annoy everybody equally, but
leave nobody a realistic opportunity to complain that SBC-4 is totally
ignoring their legitimate product requirements.
For the nascent details of the new direction see:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-071r0.pdf
The author admits in advance that much work yet needs to be done, and pleads
a lack of time to properly learn the ropes for writing a perfect proposal
straight out of the chute.
See you in New Orleans,
.Ralph


From ntw20 at earthlink.net  Thu Mar  6 08:43:03 2014
From: ntw20 at earthlink.net (Neil Wanamaker)
Date: Thu, 6 Mar 2014 08:43:03 -0800
Subject: SAT-3 call cancellation
Message-ID: <mailman.117.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Neil Wanamaker <ntw20 at earthlink.net>
*
Our facility is without power and restoration is unlikely by 1 pm.
See you all in NO.
Sent from my Samsung smartphone on AT&T
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From david.black at emc.com  Thu Mar  6 10:59:29 2014
From: david.black at emc.com (Black, David)
Date: Thu, 6 Mar 2014 13:59:29 -0500
Subject: SPC-4 section 5.6 - late letter ballot comment.
Message-ID: <mailman.118.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Black, David" <david.black at emc.com>
*
The second and third paragraphs say:
	Identifying information shall persist through power cycles (i.e., be
stored
	in non-volatile storage), hard resets, logical unit resets, I_T nexus
losses,
	media format operations, and media replacement.
	Table 61 defines the identifying information types.
The first Identifying Information Type entry in that table says:
	Peripheral device identifying information: a value describing
	the peripheral device (e.g., an operating system volume label)
The example is a problem.  Volume labels generally do not survive media
format
operations and media replacement.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA? 01748
+1 (508) 293-7953???????????? FAX: +1 (508) 293-7786
david.black at emc.com??????? Mobile: +1 (978) 394-7754
----------------------------------------------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gerry.houlder at seagate.com  Thu Mar  6 11:35:10 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Thu, 6 Mar 2014 13:35:10 -0600
Subject: SPC-4 section 5.6 - late letter ballot comment.
Message-ID: <mailman.119.1441607400.22532.t10@sandbox.t10.org>

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

I presume the peripheral device is required to keep the information
non-volatile. If the host system does something (like reformat the medium)
that should cause the identifying information to change, then the host
system is expected to send a new SET IDENTIFYING INFORMATION command to
cause the change. The host system may well want to continue using the same
device with the same volume label after the reformatting, but the
peripheral device can't know what the host system desires.
There certainly is no rule that certain events cause the identifying
information to return to some default pattern.
On Thu, Mar 6, 2014 at 12:59 PM, Black, David <david.black at emc.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Black, David" <david.black at emc.com>
> *
> The second and third paragraphs say:
>
>	  Identifying information shall persist through power cycles (i.e.,
> be stored
>	  in non-volatile storage), hard resets, logical unit resets, I_T
> nexus losses,
>	  media format operations, and media replacement.
>
>	  Table 61 defines the identifying information types.
>
> The first Identifying Information Type entry in that table says:
>
>	  Peripheral device identifying information: a value describing
>	  the peripheral device (e.g., an operating system volume label)
>
> The example is a problem.  Volume labels generally do not survive media
> format
> operations and media replacement.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953		FAX: +1 (508) 293-7786
> david.black at emc.com	     Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>


From Ralph.Weber at wdc.com  Thu Mar  6 13:40:27 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Thu, 6 Mar 2014 21:40:27 +0000
Subject: SPC-4 section 5.6 - late letter ballot comment.
Message-ID: <mailman.120.1441607400.22532.t10@sandbox.t10.org>

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

As I was told many moons ago upon arrival for my first big-time programming
job in New England, "He who proposes, disposes."
If you do not like the current example, don't whine about it. Propose a
better one.
Otherwise ... It is only an example, and your mileage may vary.
All the best,
.Ralph
________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of Gerry Houlder
[gerry.houlder at seagate.com]
Sent: Thursday, March 06, 2014 1:35 PM
To: T10 Reflector
Subject: Re: SPC-4 section 5.6 - late letter ballot comment.
I presume the peripheral device is required to keep the information
non-volatile. If the host system does something (like reformat the medium)
that should cause the identifying information to change, then the host system
is expected to send a new SET IDENTIFYING INFORMATION command to cause the
change. The host system may well want to continue using the same device with
the same volume label after the reformatting, but the peripheral device can't
know what the host system desires.
There certainly is no rule that certain events cause the identifying
information to return to some default pattern.
On Thu, Mar 6, 2014 at 12:59 PM, Black, David
<david.black at emc.com> wrote:
* From the T10 Reflector (t10 at t10.org<mailto:t10 at t10.org>), posted by:
* "Black, David" <david.black at emc.com>
*
The second and third paragraphs say:
	Identifying information shall persist through power cycles (i.e., be
stored
	in non-volatile storage), hard resets, logical unit resets, I_T nexus
losses,
	media format operations, and media replacement.
	Table 61 defines the identifying information types.
The first Identifying Information Type entry in that table says:
	Peripheral device identifying information: a value describing
	the peripheral device (e.g., an operating system volume label)
The example is a problem.  Volume labels generally do not survive media
format
operations and media replacement.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953	      FAX: +1 (508) 293-7786
david.black at emc.com        Mobile: +1 (978)
394-7754
----------------------------------------------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to
majordomo at t10.org<mailto:majordomo at t10.org>


From Paul.Suhler at Quantum.Com  Fri Mar  7 09:23:01 2014
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Fri, 7 Mar 2014 17:23:01 +0000
Subject: Leaving Quantum
Message-ID: <mailman.121.1441607400.22532.t10@sandbox.t10.org>

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

This is to let all my colleagues at T10 know that I'll be ending my work with
Quantum in two weeks.  I've really enjoyed the last fifteen and a half years
representing Seagate, Certance, and Quantum at T10 and T11, both for the
interesting work and for the interesting people.
Paul Stone will be assuming my duties as principal representative.  He'll
take over my proposals in the SSC working group.  I have one open proposal
against SPC-5 (13-362r2) which requires no further work, and Ralph or anyone
else in CAP can move that one when the time comes.
I'll let you all know where I land and whether I'll be back at T10.  After 21
March, my e-mail will be suhler [1] ieee [2] org.
[1] @
[2] .
So long and thanks for all the fish,
Paul
_____________________________________________________________________________
________________________
Paul A. Suhler, PhD | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com


From lohmeyer at t10.org  Fri Mar  7 09:56:09 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Fri, 07 Mar 2014 10:56:09 -0700
Subject: Planned outage on T10.org tomorrow Saturday March 8th
Message-ID: <mailman.122.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
On Saturday, March 8, 2014, some t10.org services will not be available from
8:00am-4:00pm MST. The t10.org server should remain up. Most work requests
will be accepted and queued up, but not processed until 4:00pm. For example,
you can request a document number, but you won't receive a response until
4:00pm.
This service interruption is due to a planned network outage while a major
UPS is replaced. As Douglas Adams would say, "Don't Panic". Please grab your
towel and be patient:
http://en.wikipedia.org/wiki/File:Towelday-Innsbruck.jpg
--
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 Ralph.Weber at wdc.com  Fri Mar  7 15:12:25 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Fri, 7 Mar 2014 23:12:25 +0000
Subject: Workload Utilization proposals upload
Message-ID: <mailman.123.1441607400.22532.t10@sandbox.t10.org>

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

Even as this missive is winging its way through the Ether(net), two SBC-4
proposals are being added to the CAP agenda. This dynamic duo represents SCSI
clones (as nearly as can be done) of the workload utilization tools already
approved for inclusion in ACS-4.
  *   14-075r0 -- SBC-4: Designed Utilization VPD data
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-075r0.pdf
  *   14-076r0 -- SBC-4: Workload Utilization logging
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-076r0.pdf
That neither of these postings meet the Two-Week rule (and the implications
thereof) should be obvious to all, and the author is certainly aware of it.
All the best,
.Ralph


From Ralph.Weber at wdc.com  Sat Mar  8 04:06:41 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Sat, 8 Mar 2014 12:06:41 +0000
Subject: Different take on ZBC Capabilities table post to T10.org
Message-ID: <mailman.124.1441607400.22532.t10@sandbox.t10.org>

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

A proposal has been uploaded that recommends changes in the 14-007r6 ZBC
Capabilities table based on the introduction of zone types that are
specialized to the host aware and host manage behaviors.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-078r0.pdf
All the best,
.Ralph


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

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Supplemental changes for SPC-4 Letter Ballot comments
(by: Ralph Weber)
T10/13-070r8   Uploaded: 2014/03/03   148209 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-070r8.pdf
SBC-4 SPC-5 Supported Block lengths and protection types VPD page
(by: William Martin)
T10/13-094r3   Uploaded: 2014/03/03   157745 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-094r3.pdf
SPC-4 Letter Ballot Comment Resolutions
(by: Ralph Weber)
T10/13-256r6   Uploaded: 2014/03/04   9050178 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r6.fdf
SPC-4 Letter Ballot Comment Resolutions
(by: Ralph Weber)
T10/13-256r6   Uploaded: 2014/03/04   5131287 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r6.pdf
SPC-4, SAM-5 Multi-LUN microcode download updates
(by: Curtis Ballard)
T10/13-267r2   Uploaded: 2014/03/04   223756 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-267r2.pdf
PQI-2 - PQI Queue Priorities
(by: Ie-Wei Njoo)
T10/14-030r0   Uploaded: 2014/03/05   278029 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-030r0.pdf
SBC-4 Per IO Advice (hints)
(by: Frederick Knight)
T10/14-065r0   Uploaded: 2014/03/07   278882 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-065r0.pdf
SAM-5: Insinuate copy manager into status precedence
(by: Ralph Weber)
T10/14-067r0   Uploaded: 2014/03/04   82458 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-067r0.pdf
SBC-4: WRITE ZEROS command
(by: Ralph Weber)
T10/14-071r0   Uploaded: 2014/03/05   121873 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-071r0.pdf
SBC-4: Designed Utilization VPD data
(by: Ralph Weber)
T10/14-075r0   Uploaded: 2014/03/07   108435 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-075r0.pdf
SBC-4: Workload Utilization logging
(by: Ralph Weber)
T10/14-076r0   Uploaded: 2014/03/07   148535 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-076r0.pdf
SPL-4 Active transmitter tuning
(by: Tim Symons)
T10/14-077r0   Uploaded: 2014/03/07   112206 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-077r0.pdf
Capabilities for ZBC devices
(by: Ralph Weber)
T10/14-078r0   Uploaded: 2014/03/08   88297 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-078r0.pdf
Working Drafts
--------------
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 36r      Uploaded: 2014/03/04   4604609 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36r.pdf
(Report generated on 2014/03/09 at 00:01:56)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From songdajian at hisilicon.com  Mon Mar 10 05:42:04 2014
From: songdajian at hisilicon.com (Songdajian)
Date: Mon, 10 Mar 2014 12:42:04 +0000
Subject: Whether "FIRST BURST" is not necessary for SAS?
Message-ID: <mailman.126.1441607400.22532.t10@sandbox.t10.org>

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

Hi,All
We are a SAS Core Design team.
We have a doubt about the feature of "FIRST BURST".
Someone said that this feature is not using in the industry and will become
obsolete .
We don't know Whether it is necessary or not to achieve the feature of "FIRST
BURST".
Can you give us some advices.
Thanks
Dajian Song


From Sanjay.Goyal at pmcs.com  Mon Mar 10 12:56:58 2014
From: Sanjay.Goyal at pmcs.com (Sanjay Goyal)
Date: Mon, 10 Mar 2014 19:56:58 +0000
Subject: Whether "FIRST BURST" is not necessary for SAS?
Message-ID: <mailman.127.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Sanjay Goyal <Sanjay.Goyal at pmcs.com>
*
Hi Dajian,
First Burst - is unsolicited data i.e. it may be received right after CMD is
received. If IO size is bigger than First Burst size, it would be more
complex algorithm for both Initiator and Target to handle part of the data as
unsolicited and part as solicited data using XFER_RDYs.
In my opinion, for small set of drives for small size IO writes, this feature
would enable higher performance, otherwise in most topologies, CMD to
XFER_RDY delay does not affect the performance negatively and hence no one
seems to bother with this feature.
sanjayG
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Songdajian
Sent: Monday, March 10, 2014 5:42 AM
To: t10 at t10.org
Cc: Yupengfei (B); Ningzuolin; Lilinhan
Subject: Whether "FIRST BURST" is not necessary for SAS?
Hi,All
We are a SAS Core Design team.
We have a doubt about the feature of "FIRST BURST".
Someone said that this feature is not using in the industry and will become=
 obsolete .
We don't know Whether it is necessary or not to achieve the feature of "FIR=
ST BURST".
Can you give us some advices.
Thanks
Dajian Song
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From david.black at emc.com  Mon Mar 10 15:09:32 2014
From: david.black at emc.com (Black, David)
Date: Mon, 10 Mar 2014 18:09:32 -0400
Subject: SPC-4 section 5.6 - late letter ballot comment.
Message-ID: <mailman.128.1441607400.22532.t10@sandbox.t10.org>

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

On reflection, Gerry's comment resolves the situation for me - if the OS
changes the volume label, the OS needs to issue a new  SET IDENTIFYING
INFORMATION command with the new volume label.
Thanks,
--David
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
Sent: Thursday, March 06, 2014 4:40 PM
To: T10 Reflector
Subject: RE: SPC-4 section 5.6 - late letter ballot comment.
As I was told many moons ago upon arrival for my first big-time programming
job in New England, "He who proposes, disposes."
If you do not like the current example, don't whine about it. Propose a
better one.
Otherwise ... It is only an example, and your mileage may vary.
All the best,
.Ralph
________________________________
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [owner-t10 at t10.org] on
behalf of Gerry Houlder [gerry.houlder at seagate.com]
Sent: Thursday, March 06, 2014 1:35 PM
To: T10 Reflector
Subject: Re: SPC-4 section 5.6 - late letter ballot comment.
I presume the peripheral device is required to keep the information
non-volatile. If the host system does something (like reformat the medium)
that should cause the identifying information to change, then the host system
is expected to send a new SET IDENTIFYING INFORMATION command to cause the
change. The host system may well want to continue using the same device with
the same volume label after the reformatting, but the peripheral device can't
know what the host system desires.
There certainly is no rule that certain events cause the identifying
information to return to some default pattern.
On Thu, Mar 6, 2014 at 12:59 PM, Black, David
<david.black at emc.com> wrote:
* From the T10 Reflector (t10 at t10.org<mailto:t10 at t10.org>), posted by:
* "Black, David" <david.black at emc.com>
*
The second and third paragraphs say:
	Identifying information shall persist through power cycles (i.e., be
stored
	in non-volatile storage), hard resets, logical unit resets, I_T nexus
losses,
	media format operations, and media replacement.
	Table 61 defines the identifying information types.
The first Identifying Information Type entry in that table says:
	Peripheral device identifying information: a value describing
	the peripheral device (e.g., an operating system volume label)
The example is a problem.  Volume labels generally do not survive media
format
operations and media replacement.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953	      FAX: +1 (508) 293-7786
david.black at emc.com        Mobile: +1 (978)
394-7754
----------------------------------------------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to
majordomo at t10.org<mailto:majordomo at t10.org>


From Neil.Wanamaker at pmcs.com  Mon Mar 10 15:39:23 2014
From: Neil.Wanamaker at pmcs.com (Neil Wanamaker)
Date: Mon, 10 Mar 2014 22:39:23 +0000
Subject: SAT-4/SPL-4 proposals
Message-ID: <mailman.129.1441607400.22532.t10@sandbox.t10.org>

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

***DO NOT DELETE OR CHANGE ANY OF THE TEXT BELOW THIS LINE***
Neil Wanamaker has scheduled this WebEx meeting.
When it's time, start or join the WebEx meeting from here:


From lohmeyer at t10.org  Tue Mar 11 09:06:38 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 11 Mar 2014 10:06:38 -0600
Subject: draft SAS Protocol / Joint PHY/Protocol Working Group minutes
  posted
Message-ID: <mailman.130.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft SAS Protocol / Joint PHY/Protocol Working Group minutes are
available at:
  http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-068r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Tue Mar 11 12:12:19 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 11 Mar 2014 13:12:19 -0600
Subject: Fwd: SAS-4/SPL-4 proposals Conference Call
Message-ID: <mailman.131.1441607400.22532.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1403111_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1403111_untitled117-11">untitled117-11</a>

Somehow, the T10 Reflector automation did not archive this message about the
SAS-4 and SPL-4 Proposals call on 15 April 2014 1:00pm-3:00pm hosted by Neil
Wanamaker. This is a second attempt to get into the reflector archive. --
John
This meeting is scheduled on behalf of Tim Symons to continue discussion of
joint SAS-4 and SPL-4 proposals. 
***DO NOT DELETE OR CHANGE ANY OF THE TEXT BELOW THIS LINE***
Neil Wanamaker has scheduled this WebEx meeting.
When it's time, start or join the WebEx meeting from here:


From Elliott at hp.com  Wed Mar 12 07:41:54 2014
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 12 Mar 2014 14:41:54 +0000
Subject: Quirky wording introduced between SPC-2 r00 and SPC-2 r01
Message-ID: <mailman.132.1441607400.22532.t10@sandbox.t10.org>

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

That change came from 97-256r2 (RBC alignment).
"No distinction" means pages are always saved (current pages are always the
same as saved pages), so SP=0 is disallowed because there's no way to not
save as requested.  If pages are never saved, then SP=1 is disallowed because
there's no way to save as requested.
---
Rob Elliott    HP Server Storage
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
Sent: Tuesday, 11 March, 2014 6:11 PM
To: t10 at t10.org
Subject: Quirky wording introduced between SPC-2 r00 and SPC-2 r01
A very old problem has come to my attention.
In SPC-2 (yes -2, circa fall 1997), r00 described the SP bit in the MODE
SELECT command as follows:
A save pages (SP) bit of zero indicates the device server shall perform the
specified MODE SELECT operation, and shall not save any pages. An SP bit of
one indicates that the device server shall perform the specified MODE SELECT
operation, and shall save to a non-volatile vendor-specific location all the
savable pages including any sent in the Data-Out Buffer. The SP bit is
optional, even when mode pages are supported by the target. Pages that are
saved are identified by the parameter savable bit that is returned in the
page header by the MODE SENSE command (see 8.3). If the PS bit is set in the
MODE SENSE data then the page shall be savable by issuing a MODE SELECT
command with the SP bit set. If the target does not implement saved pages and
the SP bit is set to one, the command shall be terminated with CHECK
CONDITION status. The sense key shall be set to ILLEGAL REQUEST, and the
additional sense code set to INVALID FIELD IN CDB.
Based on an SPC-2 r01 revision history that said, In the MODE SELECT command,
'PS bit set" has been changed to "PS bit set to one" in two places', the
paragraph became:
A save pages (SP) bit of zero indicates the device server shall perform the
specified MODE SELECT operation, and shall not save any pages. If the target
implements no distinction between current and saved pages and the SP bit is
zero, the command shall be terminated with CHECK CONDITION status. The sense
key shall be set to ILLEGAL REQUEST, and the additional sense code set to
INVALID FIELD IN CDB. An SP bit of one indicates that the device server shall
perform the specified MODE SELECT operation, and shall save to a non-volatile
vendor-specific location all the savable pages including any sent in the
Data-Out Buffer. The SP bit is optional, even when mode pages are supported
by the target. Pages that are saved are identified by the parameter savable
bit that is returned in the page header by the MODE SENSE command (see 8.3).
If the PS bit is set to one in the MODE SENSE data then the page shall be
savable by issuing a MODE SELECT command with the SP bit set to one. If the
target does not implement saved pages and the SP bit is set to one, the
command shall be terminated with CHECK CONDITION status. The sense key shall
be set to ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD
IN CDB.
This text has been maintained without changes since 1997. However, ...
There appears to be no safe SP value that the application client can use when
it does not want pages saved. Both SP=0 and SP=1 will result in a CHECK
CONDITION if the device server does not implement savable pages.
Opinions are hereby solicited. My guess is that the "no distinction" SP==0
requirement should be SP==1, but CAP has kept me hopping today and something
may have been missed.
All the best,
.Ralph


From kdbutt at us.ibm.com  Wed Mar 12 14:41:24 2014
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 12 Mar 2014 14:41:24 -0700
Subject: Tape and XCOPY (13-072r6)
Message-ID: <mailman.133.1441607400.22532.t10@sandbox.t10.org>

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

I updated the proposal based on this mornings comments.
2014/03/12 15:39:48 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-072r6.pdf
Kevin D. Butt
SCSI Architect, Tape Firmware, T10 Standards
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 Ralph.Weber at wdc.com  Wed Mar 12 16:45:10 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Wed, 12 Mar 2014 23:45:10 +0000
Subject: Revised Logical Block Markups Annex uploaded
Message-ID: <mailman.134.1441607400.22532.t10@sandbox.t10.org>

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

The inputs from T13 and T10 have been integrated into a new revision of the
proposed Logical Block Markups annex. The uploaded document is available as:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-052r1.pdf
All the best,
.Ralph


From kdbutt at us.ibm.com  Thu Mar 13 10:09:48 2014
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 13 Mar 2014 10:09:48 -0700
Subject: Tape and XCOPY (13-072r7) - recommended for inclusion has been posted
Message-ID: <mailman.135.1441607400.22532.t10@sandbox.t10.org>

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

The revisions of the Tape And XCOPY proposal that was recommended by CAP 
for inclusion in SPC-5 has been posted.
2014/03/13 11:02:48 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-072r7.pdf
Source File(s) that will be archived are:
   13-072r7.fm will be archived as 13-072r7.fm
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI Architect, Tape Firmware, T10 Standards
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 curtis.stevens at wdc.com  Thu Mar 13 12:42:42 2014
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 13 Mar 2014 19:42:42 +0000
Subject: ZBC Telecon
Message-ID: <mailman.136.1441607400.22532.t10@sandbox.t10.org>

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

Meeting Monday 24-Mar 12:30-2:30 Pacific
Curtis Stevens invites you to an online meeting using WebEx.
Meeting Number: 599 420 482
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://intercall.webex.com/intercall/j.php?J=599420482
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
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-877-351-4236  (US)
Call-in number: 1-443-863-7393	(US)
Show global numbers:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=9496727933
Conference Code: 949 672 7933
http://www.webex.com
CCP:+14438637393x9496727933#
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 Mar 13 12:44:37 2014
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 13 Mar 2014 19:44:37 +0000
Subject: ZBC Telecon
Message-ID: <mailman.137.1441607400.22532.t10@sandbox.t10.org>

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

Meeting Monday 31-Mar-14 12:30-2:30pm Pacific
Curtis Stevens invites you to an online meeting using WebEx.
Meeting Number: 591 088 707
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://intercall.webex.com/intercall/j.php?J=591088707
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
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-877-351-4236  (US)
Call-in number: 1-443-863-7393	(US)
Show global numbers:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=9496727933
Conference Code: 949 672 7933
http://www.webex.com
CCP:+14438637393x9496727933#
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 Mar 13 12:45:57 2014
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 13 Mar 2014 19:45:57 +0000
Subject: ZBC Telecon
Message-ID: <mailman.138.1441607400.22532.t10@sandbox.t10.org>

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

Meeting 7-Apr-2014 12:30-2:30pm Pacific


From curtis.stevens at wdc.com  Thu Mar 13 12:49:48 2014
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 13 Mar 2014 19:49:48 +0000
Subject: ZBC Telecon
Message-ID: <mailman.139.1441607400.22532.t10@sandbox.t10.org>

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

Meeting Monday 28-Apr-14 12:30-2:30pm Pacific
Curtis Stevens invites you to an online meeting using WebEx.
Meeting Number: 598 632 270
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://intercall.webex.com/intercall/j.php?J=598632270
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
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-877-351-4236  (US)
Call-in number: 1-443-863-7393	(US)
Show global numbers:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=9496727933
Conference Code: 949 672 7933
http://www.webex.com
CCP:+14438637393x9496727933#
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 Mar 13 12:48:07 2014
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 13 Mar 2014 19:48:07 +0000
Subject: ZBC Telecon
Message-ID: <mailman.140.1441607400.22532.t10@sandbox.t10.org>

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

Meeting Monday 14-Apr-14 12:30-2:30pm Pacific
Curtis Stevens invites you to an online meeting using WebEx.
Meeting Number: 593 176 205
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://intercall.webex.com/intercall/j.php?J=593176205
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
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-877-351-4236  (US)
Call-in number: 1-443-863-7393	(US)
Show global numbers:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=9496727933
Conference Code: 949 672 7933
http://www.webex.com
CCP:+14438637393x9496727933#
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 Mar 13 13:11:18 2014
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 13 Mar 2014 20:11:18 +0000
Subject: ZBC F2F
Message-ID: <mailman.141.1441607400.22532.t10@sandbox.t10.org>

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

F2F Meeting w/Telecon 24-Apr-14 9am ??? 5pm Mountain in Boise
Curtis Stevens invites you to an online meeting using WebEx.
Meeting Number: 593 792 655
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://intercall.webex.com/intercall/j.php?J=593792655
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
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-877-351-4236  (US)
Call-in number: 1-443-863-7393	(US)
Show global numbers:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=9496727933
Conference Code: 949 672 7933
http://www.webex.com
CCP:+14438637393x9496727933#
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 Mar 13 16:12:09 2014
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 13 Mar 2014 23:12:09 +0000
Subject: ZBC Telecon
Message-ID: <mailman.142.1441607400.22532.t10@sandbox.t10.org>

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

Meeting 7-Apr-2014 12:30-2:30pm Pacific
Curtis Stevens invites you to an online meeting using WebEx.
Meeting Number: 599 593 720
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://intercall.webex.com/intercall/j.php?J=599593720
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
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-877-351-4236  (US)
Call-in number: 1-443-863-7393	(US)
Show global numbers:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=9496727933
Conference Code: 949 672 7933
http://www.webex.com
CCP:+14438637393x9496727933#
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, discuss your concerns
with the meeting host prior to the start of the recording or do not join the
session. Please note that any such recordings may be subject to discovery in
the event of litigation.


From lohmeyer at t10.org  Fri Mar 14 10:35:13 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Fri, 14 Mar 2014 11:35:13 -0600
Subject: draft CAP Working Group minutes posted
Message-ID: <mailman.143.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft CAP Working Group minutes are available at:
  http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-069r0.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 Neil.Wanamaker at pmcs.com  Fri Mar 14 15:07:36 2014
From: Neil.Wanamaker at pmcs.com (Neil Wanamaker)
Date: Fri, 14 Mar 2014 22:07:36 +0000
Subject: SAT-3 Letter Ballot Comment Resolution
Message-ID: <mailman.144.1441607400.22532.t10@sandbox.t10.org>

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

***DO NOT DELETE OR CHANGE ANY OF THE TEXT BELOW THIS LINE***
Neil Wanamaker has scheduled this WebEx meeting.
When it's time, start or join the WebEx meeting from here:


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

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPC-5: Device Internal Status Dump
(by: Frederick Knight)
T10/13-029r2   Uploaded: 2014/03/10   264412 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-029r2.pdf
SPC-5: XCopy Tape Enhancements
(by: Kevin Butt)
T10/13-072r5   Uploaded: 2014/03/11   131602 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-072r5.pdf
SPC-5: XCopy Tape Enhancements
(by: Kevin Butt)
T10/13-072r6   Uploaded: 2014/03/12   131151 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-072r6.pdf
SPC-5: XCopy Tape Enhancements
(by: Kevin Butt)
T10/13-072r7   Uploaded: 2014/03/13   131019 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-072r7.pdf
SBC-4 SPC-5 Supported Block lengths and protection types VPD page
(by: William Martin)
T10/13-094r4   Uploaded: 2014/03/12   163909 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-094r4.pdf
SBC-4 SPC-5 Supported Block lengths and protection types VPD page
(by: William Martin)
T10/13-094r5   Uploaded: 2014/03/13   167450 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-094r5.pdf
SPC-5: Inband Bind and Unbind
(by: David L. Black)
T10/13-264r2   Uploaded: 2014/03/11   143340 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-264r2.pdf
SSC-5: Recommended Access Order
(by: Kevin Butt)
T10/13-266r4   Uploaded: 2014/03/11   127995 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-266r4.pdf
SPC-4, SAM-5 Multi-LUN microcode download updates
(by: Curtis Ballard)
T10/13-267r3   Uploaded: 2014/03/11   209130 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-267r3.pdf
SPL-4: Scrambling Methodology
(by: Bill Voorhees)
T10/13-280r1   Uploaded: 2014/03/09   449996 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-280r1.pdf
SPL-3 Letter Ballot Comments Resolutions
(by: George Penokie)
T10/13-298r6   Uploaded: 2014/03/10   3168762 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-298r6.fdf
SPL-3 Letter Ballot Comments Resolutions
(by: George Penokie)
T10/13-298r6   Uploaded: 2014/03/10   5580556 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-298r6.pdf
SPL-3 Letter Ballot Comments Resolutions
(by: George Penokie)
T10/13-298r7   Uploaded: 2014/03/13   3173458 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-298r7.fdf
SPL-3 Letter Ballot Comments Resolutions
(by: George Penokie)
T10/13-298r7   Uploaded: 2014/03/13   5593008 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-298r7.pdf
ZBC host aware model clauses for write and read commands
(by: Gerald Houlder)
T10/14-007r7   Uploaded: 2014/03/11   97192 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-007r7.pdf
SBC-4: Discussion of WCE intent
(by: Curtis Ballard)
T10/14-019r2   Uploaded: 2014/03/12   83094 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-019r2.pdf
SAS-4 PHY considerations
(by: Alvin Cox)
T10/14-024r1   Uploaded: 2014/03/10   37811 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-024r1.pdf
T13 Liaison Report
(by: Dan Colegrove)
T10/14-044r1   Uploaded: 2014/03/12   13292 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-044r1.pdf
SAT-3: Letter Ballot Comment Resolutions
(by: Neil Wanamaker)
T10/14-048r2   Uploaded: 2014/03/10   6610759 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-048r2.pdf
SAM-5: Fix TASK ABORTED status for COPY OPERATION ABORT commands
(by: Ralph Weber)
T10/14-051r1   Uploaded: 2014/03/13   134292 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-051r1.pdf
SAT-4: Logical Block Markup Descriptor annex
(by: Ralph Weber)
T10/14-052r1   Uploaded: 2014/03/12   198763 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-052r1.pdf
SAS-4.0, Low Resonance Bulk Cable Measurement
(by: Barry Olawsky)
T10/14-057r0   Uploaded: 2014/03/10   193232 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-057r0.pdf
SAS-4.0, Low Resonance Bulk Cable Measurement
(by: Barry Olawsky)
T10/14-057r0   Uploaded: 2014/03/10   670819 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-057r0.zip
Minutes of SAS Protocol/Joint PHY WG - March 10, 2014
(by: Weber/Lohmeyer)
T10/14-068r0   Uploaded: 2014/03/11   36956 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-068r0.htm
Minutes of SAS Protocol/Joint PHY WG - March 10, 2014
(by: Weber/Lohmeyer)
T10/14-068r0   Uploaded: 2014/03/11   109022 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-068r0.pdf
Minutes of CAP Working Group  - March 11-13, 2014
(by: Weber/Lohmeyer)
T10/14-069r0   Uploaded: 2014/03/14   89787 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-069r0.htm
Minutes of CAP Working Group  - March 11-13, 2014
(by: Weber/Lohmeyer)
T10/14-069r0   Uploaded: 2014/03/14   221092 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-069r0.pdf
Channel requests and important parameters
(by: Mickey Felton)
T10/14-072r0   Uploaded: 2014/03/09   390215 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-072r0.pdf
Channel requests and important parameters
(by: Mickey Felton)
T10/14-072r1   Uploaded: 2014/03/11   398093 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-072r1.pdf
SAS-4 Link Management
(by: Harvey Newman)
T10/14-073r0   Uploaded: 2014/03/09   522050 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-073r0.pdf
SAS-4 QSFP+ Cable Assembly Data
(by: Harvey Newman)
T10/14-074r0   Uploaded: 2014/03/09   789536 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-074r0.pdf
SAS-4 QSFP+ Cable Assembly Data
(by: Harvey Newman)
T10/14-074r0   Uploaded: 2014/03/09   48079438 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-074r0.zip
Capabilities for ZBC devices
(by: Ralph Weber)
T10/14-078r0   Uploaded: 2014/03/08   88297 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-078r0.pdf
ISO NWIP 14776-323 SBC-3.
(by: Gary Robinson)
T10/14-079r0   Uploaded: 2014/03/09   57958 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-079r0.docx
ISO NWIP 14776-323 SBC-3.
(by: Gary Robinson)
T10/14-079r0   Uploaded: 2014/03/10   55686 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-079r0.pdf
SAS-4/SPL-4 Modeling
(by: Bill Voorhees)
T10/14-081r0   Uploaded: 2014/03/09   766600 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-081r0.pdf
SPL-4 Summary Proposal
(by: Bill Voorhees)
T10/14-082r0   Uploaded: 2014/03/10   195502 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-082r0.pdf
SAM-5: Unit Attention clarification
(by: Frederick Knight)
T10/14-083r0   Uploaded: 2014/03/10   153783 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-083r0.pdf
SAM-5: Unit Attention clarification
(by: Frederick Knight)
T10/14-083r1   Uploaded: 2014/03/13   153368 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-083r1.pdf
SAT-3: Proposed rewrite of  9.14.2
(by: Neil Wanamaker)
T10/14-084r0   Uploaded: 2014/03/10   42913 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-084r0.pdf
IETF Liaison Report to T10
(by: David Black)
T10/14-085r0   Uploaded: 2014/03/10   1132165 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-085r0.pdf
IETF Liaison Report to T10
(by: David Black)
T10/14-085r1   Uploaded: 2014/03/13   1133051 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-085r1.pdf
Minutes of SAS PHY Working Group March 11, 2014
(by: Alvin Cox, Bill Voorhees)
T10/14-086r0   Uploaded: 2014/03/14   53016 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-086r0.pdf
SAS-4 MxS Proposal for SAS
(by: Jay Neer)
T10/14-087r0   Uploaded: 2014/03/13   820057 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-087r0.pdf
SAT-3: Apparent inconsistency between SAT-3 and SBC-3
(by: Neil Wanamaker)
T10/14-088r0   Uploaded: 2014/03/11   38340 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-088r0.pdf
SAS4 Connector and Cable Assembly Performance
(by: Brad Brubaker)
T10/14-089r0   Uploaded: 2014/03/14   2269483 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-089r0.pdf
Minutes SSC Working Group Meetings 10 March 2014
(by: Kevin Butt)
T10/14-090r0   Uploaded: 2014/03/11   21370 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-090r0.pdf
T10 Annual Report for 2013
(by: John Lohmeyer)
T10/14-091r0   Uploaded: 2014/03/11   142309 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-091r0.pdf
SSC-5: Questions on the Verify behaviors of the new VBF and VTE bits
(by: Kevin Butt)
T10/14-092r0   Uploaded: 2014/03/11   26152 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-092r0.pdf
STA - T10 Liaison Report March 13, 2014
(by: Marty Czekalski)
T10/14-093r0   Uploaded: 2014/03/12   436360 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-093r0.pdf
SSC-5 Working Group Report to Plenary, March 2014
(by: Curtis Ballard)
T10/14-094r0   Uploaded: 2014/03/12   22245 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-094r0.pdf
SSC-5 Working Group Report to Plenary, March 2014
(by: Curtis Ballard)
T10/14-094r1   Uploaded: 2014/03/13   22232 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-094r1.pdf
SNIA Liaison Report March 2014
(by: Frederick Knight)
T10/14-095r0   Uploaded: 2014/03/13   539352 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-095r0.pdf
SNIA Liaison Report March 2014
(by: Frederick Knight)
T10/14-095r0   Uploaded: 2014/03/12   1667584 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-095r0.ppt
Agenda for T10 Meeting #121
(by: John Lohmeyer)
T10/14-096r0   Uploaded: 2014/03/13   15106 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-096r0.pdf
T10 Project Summary - March 2014
(by: John Lohmeyer)
T10/14-097r0   Uploaded: 2014/03/13   29731 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-097r0.pdf
Jeopardy Letter for May 2014 meeting
(by: John Lohmeyer)
T10/14-098r0   Uploaded: 2014/03/13   30772 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-098r0.pdf
Working Drafts
--------------
SCSI / ATA Translation - 3 (SAT-3)
(Editor: Neil Wanamaker)
 Rev: 05b      Uploaded: 2014/03/10   1506708 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sat3r05b.pdf
SCSI Block Commands - 4 (SBC-4)
(Editor: William Martin)
 Rev: 01       Uploaded: 2014/03/13   2851651 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc4r01.pdf
Zoned Block Commands (ZBC)
(Editor: Curtis Stevens)
 Rev: 00       Uploaded: 2014/03/12   256289 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=zbc-r00.pdf
(Report generated on 2014/03/16 at 00:01:50)
*
* 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  Sun Mar 16 12:12:37 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Sun, 16 Mar 2014 13:12:37 -0600
Subject: draft T10 Plenary minutes posted
Message-ID: <mailman.146.1441607400.22532.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 March 13, 2014 T10 Plenary meeting #120 are
available at:
  http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-070r0.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 Ralph.Weber at wdc.com  Mon Mar 17 04:55:04 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Mon, 17 Mar 2014 11:55:04 +0000
Subject: Quirky wording introduced between SPC-2 r00 and SPC-2 r01
Message-ID: <mailman.147.1441607400.22532.t10@sandbox.t10.org>

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

In accordance with the CAP discussion of this Reflector posting, a proposed
late letter ballot comment for SPC-4 has been uploaded.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-099r0.pdf
All the best,
.Ralph
________________________________
From: Elliott, Robert (Server Storage) [Elliott at hp.com]
Sent: Wednesday, March 12, 2014 9:41 AM
To: Ralph Weber; t10 at t10.org
Subject: RE: Quirky wording introduced between SPC-2 r00 and SPC-2 r01
That change came from 97-256r2 (RBC alignment).
?No distinction? means pages are always saved (current pages are always the
same as saved pages), so SP=0 is disallowed because there?s no way to not
save as requested.  If pages are never saved, then SP=1 is disallowed because
there?s no way to save as requested.
---
Rob Elliott    HP Server Storage
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
Sent: Tuesday, 11 March, 2014 6:11 PM
To: t10 at t10.org
Subject: Quirky wording introduced between SPC-2 r00 and SPC-2 r01
A very old problem has come to my attention.
In SPC-2 (yes -2, circa fall 1997), r00 described the SP bit in the MODE
SELECT command as follows:
A save pages (SP) bit of zero indicates the device server shall perform the
specified MODE SELECT operation, and shall not save any pages. An SP bit of
one indicates that the device server shall perform the specified MODE SELECT
operation, and shall save to a non-volatile vendor-specific location all the
savable pages including any sent in the Data-Out Buffer. The SP bit is
optional, even when mode pages are supported by the target. Pages that are
saved are identified by the parameter savable bit that is returned in the
page header by the MODE SENSE command (see 8.3). If the PS bit is set in the
MODE SENSE data then the page shall be savable by issuing a MODE SELECT
command with the SP bit set. If the target does not implement saved pages and
the SP bit is set to one, the command shall be terminated with CHECK
CONDITION status. The sense key shall be set to ILLEGAL REQUEST, and the
additional sense code set to INVALID FIELD IN CDB.
Based on an SPC-2 r01 revision history that said, In the MODE SELECT command,
'PS bit set" has been changed to "PS bit set to one" in two places', the
paragraph became:
A save pages (SP) bit of zero indicates the device server shall perform the
specified MODE SELECT operation, and shall not save any pages. If the target
implements no distinction between current and saved pages and the SP bit is
zero, the command shall be terminated with CHECK CONDITION status. The sense
key shall be set to ILLEGAL REQUEST, and the additional sense code set to
INVALID FIELD IN CDB. An SP bit of one indicates that the device server shall
perform the specified MODE SELECT operation, and shall save to a non-volatile
vendor-specific location all the savable pages including any sent in the
Data-Out Buffer. The SP bit is optional, even when mode pages are supported
by the target. Pages that are saved are identified by the parameter savable
bit that is returned in the page header by the MODE SENSE command (see 8.3).
If the PS bit is set to one in the MODE SENSE data then the page shall be
savable by issuing a MODE SELECT command with the SP bit set to one. If the
target does not implement saved pages and the SP bit is set to one, the
command shall be terminated with CHECK CONDITION status. The sense key shall
be set to ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD
IN CDB.
This text has been maintained without changes since 1997. However, ...
There appears to be no safe SP value that the application client can use when
it does not want pages saved. Both SP=0 and SP=1 will result in a CHECK
CONDITION if the device server does not implement savable pages.
Opinions are hereby solicited. My guess is that the "no distinction" SP==0
requirement should be SP==1, but CAP has kept me hopping today and something
may have been missed.
All the best,
.Ralph


From lohmeyer at t10.org  Mon Mar 17 13:44:09 2014
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 17 Mar 2014 14:44:09 -0600
Subject: Tentative 2016 T10 meeting weeks
Message-ID: <mailman.148.1441607400.22532.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
I have selected tentative T10 meeting weeks for 2016:
  January   11-15, 2016
  March      7-11, 2016
  May	      2-6, 2016
  July	    11-15, 2016
  September 12-16, 2016
  November   7-11, 2016
I think I have missed overlapping major holidays and the IETF meeting weeks.
I will prepare an approval motion for these dates at the May T10 meeting. If
you are interested in hosting any of these meetings, please tell/remind me.
BTW, The September 14-18, 2015 T10 meeting week overlaps the Jewish Rosh
Hashana holiday (Jewish New Year), which is on the 14th-15th. I do not see a
good solution as the previous week includes Labor Day and the following week
includes Yom Kippur (9/23).
--
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 benber.ning at hisilicon.com  Fri Mar 21 01:03:35 2014
From: benber.ning at hisilicon.com (Ningzuolin)
Date: Fri, 21 Mar 2014 08:03:35 +0000
Subject: =?gb2312?B?SG93IGFib3V0IHRoZSBzY2hlZHVsZSBvZiBTQVM0LjAgU3BlY6O/?=
Message-ID: <mailman.149.1441607400.22532.t10@sandbox.t10.org>

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

Hi All
How about the schedule of SAS4.0 Spec??
BR
?????? (Benber)
TEL: (86)0755-28426953	FAX: (86)0755-28426972
????????????????????????????????D3 ??????????????????????????
D3 Building Huawei Technologies Co., Ltd.Bantian, Longgang District Shenzhen
?????????????????????????????????????????????????????????????????????????????
?????????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????
This e-mail and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including, but
not limited to, total or partial disclosure, reproduction, or dissemination)
by persons other than the intended recipient(s) is prohibited. If you receive
this e-mail in error, please notify the sender by phone or email immediately
and delete it!


From Ralph.Weber at wdc.com  Fri Mar 21 02:49:17 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Fri, 21 Mar 2014 09:49:17 +0000
Subject: =?gb2312?B?UkU6IEhvdyBhYm91dCB0aGUgc2NoZWR1bGUgb2YgU0FTNC4wIFNwZWOjvw==?=
Message-ID: <mailman.150.1441607400.22532.t10@sandbox.t10.org>

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

The schedules for all T10 projects are published (and updated regularly) in:
http://www.t10.org/ftp/t10/proj132.txt
SAS-4 is the third line in the DEVELOPMENT section.
All the best,
.Ralph
________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of Ningzuolin
[benber.ning at hisilicon.com]
Sent: Friday, March 21, 2014 3:03 AM
To: t10 at t10.org
Subject: How about the schedule of SAS4.0 Spec??
Hi All
How about the schedule of SAS4.0 Spec??
BR
?????? (Benber)
TEL: (86)0755-28426953	FAX: (86)0755-28426972
????????????????????????????????D3 ??????????????????????????
D3 Building Huawei Technologies Co., Ltd.Bantian, Longgang District Shenzhen
?????????????????????????????????????????????????????????????????????????????
?????????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????
This e-mail and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including, but
not limited to, total or partial disclosure, reproduction, or dissemination)
by persons other than the intended recipient(s) is prohibited. If you receive
this e-mail in error, please notify the sender by phone or email immediately
and delete it!


From Ralph.Weber at wdc.com  Fri Mar 21 18:30:31 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Sat, 22 Mar 2014 01:30:31 +0000
Subject: Pre-forwarding SPC-4 letter ballot files posted
Message-ID: <mailman.151.1441607400.22532.t10@sandbox.t10.org>

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

All SPC-4 letter ballot comments are resolved and (with the exception of two
front-matter comments) all resolutions are incorporated in SPC-4 r36s.
For the time being, the editor's work is done. Now, you must review the SPC-4
letter ballot information and prepare to vote on forwarding to public review
during the May meeting week.
Complaints registered via e-mail will be welcomed until the April 18 (i.e.,
the time of the T13 meeting week).
The usual cast of files are (or soon will be) available.
SPC-4 r36s:
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36s.pdf
People-friendly letter ballot comments report:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r7.pdf
Supplemental file for letter ballot comments resolutions:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-070r8.pdf
SPC-4 r36 (for loading Acrobat format comments):
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36.pdf
Acrobat-format comments database:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r7.fdf
All the best,
.Ralph


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

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPC-5 Add more environment parameters to Temperature log page
(by: Gerald Houlder)
T10/13-253r3   Uploaded: 2014/03/20   144210 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-253r3.pdf
SPC-4 Letter Ballot Comment Resolutions
(by: Ralph Weber)
T10/13-256r7   Uploaded: 2014/03/21   9047740 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r7.fdf
SPC-4 Letter Ballot Comment Resolutions
(by: Ralph Weber)
T10/13-256r7   Uploaded: 2014/03/21   5264868 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-256r7.pdf
T10 Style Guide 3rd Edition
(by: George Penokie)
T10/14-006r1   Uploaded: 2014/03/19   883458 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-006r1.pdf
SAM-5: iSCSI Update
(by: Frederick Knight)
T10/14-016r2   Uploaded: 2014/03/18   192239 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-016r2.pdf
SAM-5: Insinuate copy manager into status precedence
(by: Ralph Weber)
T10/14-067r1   Uploaded: 2014/03/16   83581 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-067r1.pdf
Minutes of CAP Working Group  - March 11-13, 2014
(by: Weber/Lohmeyer)
T10/14-069r0   Uploaded: 2014/03/17   93184 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-069r0.htm
Minutes of T10 Plenary Meeting #120  - March 13, 2014
(by: Weber/Lohmeyer)
T10/14-070r0   Uploaded: 2014/03/16   121709 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-070r0.htm
Minutes of T10 Plenary Meeting #120  - March 13, 2014
(by: Weber/Lohmeyer)
T10/14-070r0   Uploaded: 2014/03/16   281886 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-070r0.pdf
SAS-4 MxS Proposal for SAS
(by: Jay Neer)
T10/14-087r1   Uploaded: 2014/03/19   445134 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-087r1.pdf
SPC-4 LB: Clarify case where all mode pages are savable mode pages
(by: Ralph Weber)
T10/14-099r0   Uploaded: 2014/03/17   80979 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-099r0.pdf
Working Drafts
--------------
SCSI Architecture Model - 5 (SAM-5)
(Editor: George Penokie)
 Rev: 16       Uploaded: 2014/03/19   1630732 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sam5r16.pdf
Serial Attached SCSI - 3 (SAS-3)
(Editor: Alvin Cox)
 Rev: 06       Uploaded: 2014/03/18   54313207 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sas3r06.zip
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 36s      Uploaded: 2014/03/21   4610728 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36s.pdf
SAS Protocol Layer - 3 (SPL-3)
(Editor: George Penokie)
 Rev: 06g      Uploaded: 2014/03/18   9751681 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl3r06g.pdf
(Report generated on 2014/03/23 at 00:01:52)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Ralph.Weber at wdc.com  Mon Mar 24 08:54:21 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Mon, 24 Mar 2014 15:54:21 +0000
Subject: Trio of SPC-5 obsolescence documents posted
Message-ID: <mailman.153.1441607400.22532.t10@sandbox.t10.org>

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

Building on the tradition established by Kevin Butt (13-072r7) and Paul
Suhler (12-362r2), I have posted three documents that carry forward all the
obsolescence ideas deferred out of the SPC-4 letter ballot.
More Device Types House Cleaning
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-100r0.pdf
Kiss SPI-5 Goodbye
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-101r0.pdf
Make SAS-2 Power Conditions Management History
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-102r0.pdf
I believe this is all the deferred SPC pillaging, but would not be surprised
to hear that other SPC-4 letter ballot comments envisioned more excisions.
All the best,
.Ralph


From gerry.houlder at seagate.com  Mon Mar 24 11:33:55 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Mon, 24 Mar 2014 13:33:55 -0500
Subject: Planning a proposal to obsolete EER and DCR bits
Message-ID: <mailman.154.1441607400.22532.t10@sandbox.t10.org>

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

Hi,
I am planning to write a proposal to obsolete the EER and DCR bits in the
Read Write Recovery mode page (Verify Recovery page would be affected
also). I believe these have outlived their usefulness.
For disks (both HDD and SSD) most implementations ignore the EER bit today.
For DCR, most implementations might disable their most extreme error
correction steps (e.g., erasure pointer steps) but no one disables all ECC
type correction steps like the standard says today. Rather than fix that
wording, I would rather obsolete the bit entirely.
If anyone has a convincing reason against obsoleting these bits, please
contact me either directly or on the reflector.


From gerry.houlder at seagate.com  Mon Mar 24 11:49:06 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Mon, 24 Mar 2014 13:49:06 -0500
Subject: 14-007r8 and 14-025r3 posted at T10 web site
Message-ID: <mailman.155.1441607400.22532.t10@sandbox.t10.org>

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

14-007r8 and 14-025r3 are posted at the T10 web site. These are available
for discussion at the upcoming ZBC telecon.


From curtis.stevens at wdc.com  Mon Mar 24 14:33:30 2014
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Mon, 24 Mar 2014 21:33:30 +0000
Subject: ZBC Telecon
Message-ID: <mailman.156.1441607400.22532.t10@sandbox.t10.org>

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

Meeting 7-Apr-2014 12:30-2:30pm Pacific
Curtis Stevens invites you to an online meeting using WebEx.
Meeting Number: 599 593 720
Meeting Password: This meeting does not require a password.
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://intercall.webex.com/intercall/j.php?J=599593720
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
-------------------------------------------------------
Provide your phone number when you join the meeting to receive a call back.
Alternatively, you can call:
Call-in toll-free number: 1-877-351-4236  (US)
Call-in number: 1-443-863-7393	(US)
Show global numbers:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=9496727933
Conference Code: 949 672 7933
http://www.webex.com
CCP:+14438637393x9496727933#
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 pak-lung.seto at intel.com  Tue Mar 25 10:46:54 2014
From: pak-lung.seto at intel.com (Seto, Pak-lung)
Date: Tue, 25 Mar 2014 17:46:54 +0000
Subject: May T10 reservation
Message-ID: <mailman.157.1441607400.22532.t10@sandbox.t10.org>

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

Just a reminder, the deadline to make hotel reservation for the May T10
meeting is Next Friday 4/4.
Pak


From pak-lung.seto at intel.com  Tue Mar 25 13:58:09 2014
From: pak-lung.seto at intel.com (Seto, Pak-lung)
Date: Tue, 25 Mar 2014 20:58:09 +0000
Subject: Issue when booking May T10 meeting - especially on Sunday night
Message-ID: <mailman.158.1441607400.22532.t10@sandbox.t10.org>

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

If you have problem booking the May T10 hotel - Marriott, especially Sunday
night.
Please try it again now, the hotel just inform me that they have fixed the
booking issue.
Pak


From gerry.houlder at seagate.com  Fri Mar 28 12:55:28 2014
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Fri, 28 Mar 2014 14:55:28 -0500
Subject: Usage for LOGICAL UNIT NOT READY, SA CREATION IN PROGRESS sense bytes
Message-ID: <mailman.159.1441607400.22532.t10@sandbox.t10.org>

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

Hi,
I have noticed that LOGICAL UNIT NOT READY, SA CREATION IN PROGRESS sense
code is described is SPC-4 as specifically tied to IKEv2-SCSI protocol
negotiation sequences.
My company sees a need to use a similar ASC/ ASCQ for TCG security
sessions. The question is -- is it OK to use exactly the same sense bytes
for a TCG session (or other security protocol session) or do i need to
define a new ASC/ ASCQ that will read something like "LOGICAL UNIT NOT
READY, SECURITY SESSION OPEN"?
Please respond with opinions to the T10 reflector. If sentiment is against
using this code for security session other than IKEv2-SCSI, then i will
bring a proposal to the May T10 meeting to create the new sense code.


From Ralph.Weber at wdc.com  Fri Mar 28 13:57:30 2014
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Fri, 28 Mar 2014 20:57:30 +0000
Subject: Usage for LOGICAL UNIT NOT READY, SA CREATION IN PROGRESS sense
 bytes
Message-ID: <mailman.160.1441607400.22532.t10@sandbox.t10.org>

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

Gerry,
I am having a hard time imaging a case where the application client needs a
special ASC/ASCQ to tell it what security protocol (e.g., IKEv2-SCSI or TCG)
its running.
The chances of sharing code between these two incredibly tiny (to say the
least). So, one codepoint should suffice for all.
All the best,
.Ralph
________________________________
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of Gerry Houlder
[gerry.houlder at seagate.com]
Sent: Friday, March 28, 2014 2:55 PM
To: T10 Reflector
Subject: Usage for LOGICAL UNIT NOT READY, SA CREATION IN PROGRESS sense
bytes
Hi,
I have noticed that LOGICAL UNIT NOT READY, SA CREATION IN PROGRESS sense
code is described is SPC-4 as specifically tied to IKEv2-SCSI protocol
negotiation sequences.
My company sees a need to use a similar ASC/ ASCQ for TCG security sessions.
The question is -- is it OK to use exactly the same sense bytes for a TCG
session (or other security protocol session) or do i need to define a new
ASC/ ASCQ that will read something like "LOGICAL UNIT NOT READY, SECURITY
SESSION OPEN"?
Please respond with opinions to the T10 reflector. If sentiment is against
using this code for security session other than IKEv2-SCSI, then i will bring
a proposal to the May T10 meeting to create the new sense code.


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

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
ZBC host aware model clauses for write and read commands
(by: Gerald Houlder)
T10/14-007r8   Uploaded: 2014/03/24   95625 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-007r8.pdf
ZBC common model references (clause 4)
(by: Gerald Houlder)
T10/14-025r3   Uploaded: 2014/03/24   49473 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-025r3.pdf
Style Guide ISO modifications to normative reference section
(by: George Penokie)
T10/14-039r2   Uploaded: 2014/03/25   128652 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-039r2.pdf
SAM-5: State Machines Makeover
(by: George Penokie)
T10/14-054r1   Uploaded: 2014/03/26   168830 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-054r1.pdf
Minutes of T10 Plenary Meeting #120  - March 13, 2014
(by: Weber/Lohmeyer)
T10/14-070r1   Uploaded: 2014/03/24   121839 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-070r1.htm
Minutes of T10 Plenary Meeting #120  - March 13, 2014
(by: Weber/Lohmeyer)
T10/14-070r1   Uploaded: 2014/03/24   286867 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-070r1.pdf
Establish baseline for SPC-5 device types list
(by: Ralph Weber)
T10/14-100r0   Uploaded: 2014/03/24   136470 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-100r0.pdf
Oust SPI-5 from SPC-5
(by: Ralph Weber)
T10/14-101r0   Uploaded: 2014/03/24   135200 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-101r0.pdf
SPC-5: Obsolete SAS-2 Power Management codepoints
(by: Ralph Weber)
T10/14-102r0   Uploaded: 2014/03/24   90965 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-102r0.pdf
Working Drafts
--------------
(Report generated on 2014/03/30 at 00:01:51)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From pak-lung.seto at intel.com  Mon Mar 31 10:32:47 2014
From: pak-lung.seto at intel.com (Seto, Pak-lung)
Date: Mon, 31 Mar 2014 17:32:47 +0000
Subject: Hotel reservation deadline this Friday 4/4 for the May T10 meeting
 in Vancouver
Message-ID: <mailman.162.1441607400.22532.t10@sandbox.t10.org>

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

For those who wants to wait till the last minute, just a reminder, the
deadline to make hotel reservation for the May T10 meeting is this Friday
4/4.
Please use the provided reservation link to make your reservation.  The hotel
has reserved a block of rooms for our meeting, if you have trouble to make
reservation due to running out of the reserved room block, please let me know
ASAP so that I can request for more rooms available on particular nights. 
May starts the busy tourist season in Vancouver.
See you soon in Vancouver.  I think you still can try King Crabs in May in
Vancouver - only one block from the hotel....... :)
Pak


From pak-lung.seto at intel.com  Mon Mar 31 11:12:57 2014
From: pak-lung.seto at intel.com (Seto, Pak-lung)
Date: Mon, 31 Mar 2014 18:12:57 +0000
Subject: Hotel reservation deadline this Friday 4/4 for the May T10
 meeting in Vancouver
Message-ID: <mailman.163.1441607400.22532.t10@sandbox.t10.org>

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

If you encountered "no rooms available" with the reservation, please let me
know ASAP.
I am letting the hotel know to see if they can add more rooms.
Pak
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Seto,
Pak-lung
Sent: Monday, March 31, 2014 1:33 PM
To: T10 at t10.org
Subject: Hotel reservation deadline this Friday 4/4 for the May T10 meeting
in Vancouver
For those who wants to wait till the last minute, just a reminder, the
deadline to make hotel reservation for the May T10 meeting is this Friday
4/4.
Please use the provided reservation link to make your reservation.  The hotel
has reserved a block of rooms for our meeting, if you have trouble to make
reservation due to running out of the reserved room block, please let me know
ASAP so that I can request for more rooms available on particular nights. 
May starts the busy tourist season in Vancouver.
See you soon in Vancouver.  I think you still can try King Crabs in May in
Vancouver - only one block from the hotel....... :)
Pak


From pak-lung.seto at intel.com  Mon Mar 31 11:53:22 2014
From: pak-lung.seto at intel.com (Seto, Pak-lung)
Date: Mon, 31 Mar 2014 18:53:22 +0000
Subject: May T10 booking issue
Message-ID: <mailman.164.1441607400.22532.t10@sandbox.t10.org>

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

There are rooms available for our meeting.
But it seems the hotel booking site has problem booking Thursday night (check
out on the 9th), i.e. if you check out on the 8th, it is OK, but it will give
you "no rooms available" error message if you have checkout on Friday the
9th.
The hotel is looking into the problem now, if you encounter the "no rooms
available" message, please call the hotel reservation to book directly until
the problem is solved.
If you have problem booking by calling the hotel, please let me know ASAP.
Pak


From pak-lung.seto at intel.com  Mon Mar 31 12:05:37 2014
From: pak-lung.seto at intel.com (Seto, Pak-lung)
Date: Mon, 31 Mar 2014 19:05:37 +0000
Subject: May T10 booking issue
Message-ID: <mailman.165.1441607400.22532.t10@sandbox.t10.org>

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

Some of you have successfully booking on checking out on Friday the 9th.
Let me know if you have any booking issues.
Pak
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Seto,
Pak-lung
Sent: Monday, March 31, 2014 2:53 PM
To: T10 at t10.org
Subject: May T10 booking issue
There are rooms available for our meeting.
But it seems the hotel booking site has problem booking Thursday night (check
out on the 9th), i.e. if you check out on the 8th, it is OK, but it will give
you "no rooms available" error message if you have checkout on Friday the
9th.
The hotel is looking into the problem now, if you encounter the "no rooms
available" message, please call the hotel reservation to book directly until
the problem is solved.
If you have problem booking by calling the hotel, please let me know ASAP.
Pak


From paulw at marvell.com  Mon Mar 31 12:24:09 2014
From: paulw at marvell.com (Paul Wassenberg)
Date: Mon, 31 Mar 2014 12:24:09 -0700
Subject: May T10 booking issue
Message-ID: <mailman.166.1441607400.22532.t10@sandbox.t10.org>

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

I succeeded by trying multiple times, and it eventually worked....
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Seto,
Pak-lung
Sent: Monday, March 31, 2014 12:06 PM
To: T10 at t10.org
Subject: RE: May T10 booking issue
Some of you have successfully booking on checking out on Friday the 9th.
Let me know if you have any booking issues.
Pak
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Seto, Pak-lung
Sent: Monday, March 31, 2014 2:53 PM
To: T10 at t10.org<mailto:T10 at t10.org>
Subject: May T10 booking issue
There are rooms available for our meeting.
But it seems the hotel booking site has problem booking Thursday night (check
out on the 9th), i.e. if you check out on the 8th, it is OK, but it will give
you "no rooms available" error message if you have checkout on Friday the
9th.
The hotel is looking into the problem now, if you encounter the "no rooms
available" message, please call the hotel reservation to book directly until
the problem is solved.
If you have problem booking by calling the hotel, please let me know ASAP.
Pak


From pak-lung.seto at intel.com  Mon Mar 31 12:35:49 2014
From: pak-lung.seto at intel.com (Seto, Pak-lung)
Date: Mon, 31 Mar 2014 19:35:49 +0000
Subject: May T10 booking issue
Message-ID: <mailman.167.1441607400.22532.t10@sandbox.t10.org>

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

I tested by booking checkout date on the 9th, it works.
Pak
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Paul
Wassenberg
Sent: Monday, March 31, 2014 3:24 PM
To: T10 at t10.org
Subject: RE: May T10 booking issue
I succeeded by trying multiple times, and it eventually worked....
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Seto, Pak-lung
Sent: Monday, March 31, 2014 12:06 PM
To: T10 at t10.org<mailto:T10 at t10.org>
Subject: RE: May T10 booking issue
Some of you have successfully booking on checking out on Friday the 9th.
Let me know if you have any booking issues.
Pak
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Seto, Pak-lung
Sent: Monday, March 31, 2014 2:53 PM
To: T10 at t10.org<mailto:T10 at t10.org>
Subject: May T10 booking issue
There are rooms available for our meeting.
But it seems the hotel booking site has problem booking Thursday night (check
out on the 9th), i.e. if you check out on the 8th, it is OK, but it will give
you "no rooms available" error message if you have checkout on Friday the
9th.
The hotel is looking into the problem now, if you encounter the "no rooms
available" message, please call the hotel reservation to book directly until
the problem is solved.
If you have problem booking by calling the hotel, please let me know ASAP.
Pak