From Ralph.Weber at wdc.com  Mon Feb  2 15:18:36 2015
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Mon, 2 Feb 2015 23:18:36 +0000
Subject: SBC-4 Logical Block model changes updated based on ZBC call inputs
Message-ID: <mailman.68.1441607016.22458.t10@sandbox.t10.org>

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

The issues raised during today's ZBC conference call have been integrated in
the latest revision of the proposed changes to the SBC-4 Logical Blocks
model, see:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-062r2.pdf
All the best,
.Ralph


From bill.martin at ssi.samsung.com  Wed Feb  4 11:23:41 2015
From: bill.martin at ssi.samsung.com (Bill Martin-SSI)
Date: Wed, 4 Feb 2015 19:23:41 +0000
Subject: Ltest SBC-4 has been posted
Message-ID: <mailman.69.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill Martin-SSI <bill.martin at ssi.samsung.com>
*
SBC-4r05 has been posted for your reading pleasure.
Bill Martin
SSD I/O Standards 
Samsung Semiconductor, Inc. 
Cell (408) 499-1839
-----Original Message-----
From: T10 Working Draft Administrator [mailto:lohmeyer at t10.org] 
Sent: Wednesday, February 04, 2015 11:19 AM
To: Bill Martin-SSI
Cc: John Lohmeyer
Subject: Re: Re: T10 Working Draft Assignment: sbc4r05
2015/02/04 12:19:18 
Your request to upload a file or files to the T10 site has been accepted.
Your file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc4r05.pdf
Source File(s) that will be archived are:
   sbc4r05.zip will be archived as sbc4r05.zip
Normally, the posting/archiving process takes about 30 minutes.
Please contact John Lohmeyer <lohmeyer at t10.org> should you need further
assistance.
bill.martin at ssi.samsung.com wrote:
> Date: Wed Feb  4 13:11:34 2015
> From: bill.martin at ssi.samsung.com
> To: T10 Document Administrator via web upload <docs at t10.org>
> Subject: Re: T10 Working Draft Assignment: sbc4r05
> 
> T10 working draft upload details:
> 
>	    Project:  
>     Working Draft: sbc4r05
>	Upload Code: AC_03860lmnpvkI05B
>	 Draft_Date: 2015/01/21
>      Draft_Author: William Martin
>	Draft_Title: SCSI Block Commands - 4 (SBC-4) ##
>  Current_Revision: Yes
>	  Post_File: pdf
> 
> ## COPYRIGHT POLICY
> ## ----------------
> ##
> ## All Working Drafts should contain the following copyright ## 
> statement on the cover page:
> ##
> ##   Permission is granted to members of INCITS, its technical
> ##   committees and their associated task groups to reproduce
> ##   this document for the purposes of INCITS standardization
> ##   activities without further permission, provided this notice 
> ##   is included. All other rights are reserved. Any duplication 
> ##   of this document for commercial or for-profit use is 
> ##   strictly prohibited.
> ##
> Attachment Converted: "D:\T10\ATTACH\sbc4r05.pdf"
> 
> Attachment Converted: "D:\T10\ATTACH\sbc4r05.zip"
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From bill.martin at ssi.samsung.com  Thu Feb  5 15:09:31 2015
From: bill.martin at ssi.samsung.com (Bill Martin-SSI)
Date: Thu, 5 Feb 2015 23:09:31 +0000
Subject: Updated 14-275 posted
Message-ID: <mailman.70.1441607016.22458.t10@sandbox.t10.org>

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

I have posted an update to 14-275 based on the inputs from last week's
conference call. Please review. I will take comments and try to roll another
version prior to the next Storage Intelligence conference call.
Bill Martin
SSD I/O Standards
Samsung Semiconductor, Inc.
Cell (408) 499-1839


From lohmeyer at t10.org  Sat Feb  7 23:03:40 2015
From: lohmeyer at t10.org (T10 Administrator)
Date: Sun, 8 Feb 2015 02:03:40 -0500
Subject: Recent T10 documents uploaded since 2015/02/01
Message-ID: <mailman.71.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC4: Storage Intelligence
(by: William Martin)
T10/14-275r4   Uploaded: 2015/02/05   413876 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-275r4.pdf
SBC-4 Revise Logical Block Model to support block device extension
technologies
(by: Ralph Weber)
T10/15-062r2   Uploaded: 2015/02/02   82572 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-062r2.pdf
Working Drafts
--------------
SCSI Block Commands - 4 (SBC-4)
(Editor: William Martin)
 Rev: 05       Uploaded: 2015/02/04   3014787 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc4r05.pdf
(Report generated on 2015/02/08 at 00:03:25)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From curtis.stevens at wdc.com  Mon Feb  9 14:22:10 2015
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Mon, 9 Feb 2015 22:22:10 +0000
Subject: Canceled: ZBC Letter Ballot Comment Resolution
Message-ID: <mailman.72.1441607016.22458.t10@sandbox.t10.org>

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

ZBC Letter Ballot Comment Resolution

150216 ??? 12:30-2:30 Pacific Time



From lohmeyer at t10.org  Tue Feb 10 10:35:50 2015
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 10 Feb 2015 11:35:50 -0700
Subject: DNS issue
Message-ID: <mailman.73.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Several people have noticed one of the promised glitches caused by 
switching the DNS server for T10.org. Apparently, ftp.t10.org was set to 
an old IP address for t10.org that in use before August 2014. Yesterday, 
Curtis Stevens requested that ftp.t10.org be changed to 192.19.224.106, 
which is the correct address for t10.org, ftp.t10.org and www.t10.org.
If you are still having trouble using ftp.t10.org, either the fix has 
not yet propagated through the net to you, or you have a cached copy of 
the wrong IP address. A quick workaround is to use t10.org wherever you 
would use ftp.t10.org. If you are on a Windows machine, you can update 
your cache by opening a command prompt and typing:
   ipconfig /flushdns
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Tue Feb 10 13:32:40 2015
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Tue, 10 Feb 2015 21:32:40 +0000
Subject: Tomorrows T10 BIND con-call
Message-ID: <mailman.74.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
Here is the document for tomorrows con-call (12-2 Pacific, 3-5 Eastern):
  http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-146r7.pdf 
David Black invites you to an online meeting using WebEx.
Meeting Number: 640 055 120
Meeting Password: This meeting does not require a password. 
-------------------------------------------------------
To join this meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://emccorp.webex.com/emccorp/j.php?J=640055120
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-888-6433084  (US)
Call-in number: 1-857-2074204  (US)
Attendee access code: 122 099 67
-----------------------------------------------------------------------------
----------------------
-----Original Message-----
From: T10 Document Administrator [mailto:lohmeyer at t10.org] 
Sent: Tuesday, February 10, 2015 3:21 PM
To: Knight, Frederick
Subject: Re: Re: T10 Document Number Assigned (T10/14-146r7)
2015/02/10 13:20:47 
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=14-146r7.pdf 
Source File(s) that will be archived are:
   14-146r7.fm will be archived as 14-146r7.fm
Normally, the posting/archiving process takes about 30 minutes.
Please contact John Lohmeyer <lohmeyer at t10.org>
should you need further assistance.
Frederick.Knight at netapp.com wrote:
> Date: Tue Feb 10 14:13:16 2015
> From: Frederick.Knight at netapp.com
> To: T10 Document Administrator via web upload <docs at t10.org>
> Subject: Re: T10 Document Number Assigned (T10/14-146r7)
> 
> T10 document upload details:
> 
>   Document Number: T10/14-146r7
>	Upload Code: AC_03862exhjnal32u
>     Document_Date: 2015/02/09
>   Document_Author: Frederick Knight
>    Document_Title: SPC-5: Combined BIND/UNBIND/Rebind
>    Meeting_Agenda: none
>   Meeting_Agenda2: none
> Document_Comments: <none>
>      Other_Number: <none>
>	  Post_File: pdf
> 
> ## COPYRIGHT POLICY
> ## ----------------
> ##
> ## Do not submit documents containing a copyright statement
> ## unless you add the following statement:
> ##
> ##	Permission is granted to members of INCITS, its technical
> ##	committees and their associated task groups to reproduce
> ##	this document for the purposes of INCITS standardization
> ##	activities, provided this notice is included.
> ##
> ## If you upload a copyrighted document, with or without
> ## this statement, it will be assumed implicitly that you
> ## and your organization have given the above permission.
> ##
> ##
> ## APPROPRIATE CONTENT
> ## -------------------
> ##
> ## Do not upload inappropriate material.  If you do, your
> ## files will be removed and your posting privileges will
> ## be revoked.
> 
> Attachment Converted: "D:\T10\ATTACH\14-146r7.pdf"
> 
> Attachment Converted: "D:\T10\ATTACH\14-146r7.fm"
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From alvin.cox at seagate.com  Wed Feb 11 10:51:42 2015
From: alvin.cox at seagate.com (Alvin Cox)
Date: Wed, 11 Feb 2015 12:51:42 -0600
Subject: No SAS PHY teleconference 2/12/15
Message-ID: <mailman.75.1441607016.22458.t10@sandbox.t10.org>

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1502110_nameless-3864-2-1.html">nameless-3864-2-1.html</a>

I have not received any notice of material to be presented so I am
canceling the SAS PHY call this week. I will schedule a meeting in the
future if one is needed prior to the March F2F. Please note that I will not
be available to conduct a call on 2/26.
-- 
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809
Office 405-392-3738
E-Mail	alvin.cox at seagate.com


From kdbutt at us.ibm.com  Wed Feb 11 14:02:29 2015
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 11 Feb 2015 15:02:29 -0700
Subject: Saveable mode pages
Message-ID: <mailman.76.1441607016.22458.t10@sandbox.t10.org>

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

I am confused by 6.12.5 Saved values 
<<All saveable mode pages should be considered saved if a MODE SELECT 
command issued with the SP bit set to one has completed with a GOOD status 
or after the successful completion of a FORMAT UNIT command.>>
This states that after the successful completion of a FORMAT UNIT command 
ALL saveable mode pages should be considered saved. This may be good for 
block devices, but why are tape devices included in this? On tape devices 
a FORMAT UNIT command formats the tape but does not change other things in 
the device - nor do we want it to.  Also, I can interpret this to say, 
when doing a FORMAT UNIT command part of the processing is to take all the 
Current values of mode pages that are saveable and save them. This may 
violate the intent of the application client which explicitly did not set 
the SP bit in the MODE SELECT that updated the Current values (and 
explicitly did not update them to Saved values).
Is anybody else bothered by this?
Kevin D. Butt
SCSI Architect, Tape Firmware, CAMSS
T10 Standards
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From gerry.houlder at seagate.com  Wed Feb 11 18:36:45 2015
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Wed, 11 Feb 2015 20:36:45 -0600
Subject: Saveable mode pages
Message-ID: <mailman.77.1441607016.22458.t10@sandbox.t10.org>

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

It is interesting that SPC-4 promises behavior of FORMAT UNIT command when
FORMAT UNIT command is not included in SPC-4 and there isn't even a "see
command standard" reference. I think you would be happier with a statement
like "Saveable mode pages may also be saved by a FORMAT UNIT command (see
SBC-4 and SSC-x)". i guess we missed this during letter ballot review last
year.
On Wed, Feb 11, 2015 at 4:02 PM, Kevin D Butt <kdbutt at us.ibm.com> wrote:
> I am confused by *6.12.5 Saved values*
> <<All saveable mode pages should be considered saved if a MODE SELECT
> command issued with the SP bit set to one has completed with a GOOD
> status or after the successful completion of a FORMAT UNIT command.>>
>
> This states that after the successful completion of a FORMAT UNIT command
> ALL saveable mode pages should be considered saved. This may be good for
> block devices, but why are tape devices included in this? On tape devices a
> FORMAT UNIT command formats the tape but does not change other things in
> the device - nor do we want it to.  Also, I can interpret this to say, when
> doing a FORMAT UNIT command part of the processing is to take all the
> Current values of mode pages that are saveable and save them. This may
> violate the intent of the application client which explicitly did not set
> the SP bit in the MODE SELECT that updated the Current values (and
> explicitly did not update them to Saved values).
>
> Is anybody else bothered by this?
>
> Kevin D. Butt
> SCSI Architect, Tape Firmware, CAMSS
> T10 Standards
> 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 Ralph.Weber at wdc.com  Thu Feb 12 05:13:32 2015
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Thu, 12 Feb 2015 13:13:32 +0000
Subject: Saveable mode pages
Message-ID: <mailman.78.1441607016.22458.t10@sandbox.t10.org>

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1502120_nameless-3200-2-1.html">nameless-3200-2-1.html</a>

If there is a decent consensus that adding some "(see ...)" text resolves the
original issue, I have no problem incorporating that in SPC-5 r04 as an
editorial change.
If the headaches are bigger and a cleanup proposal is needed, then I would
rather have the addition on record in an approved proposal.
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: Wednesday, February 11, 2015 8:36 PM
To: Kevin D Butt
Cc: Curtis Ballard; Paul Stone (Paul.Stone at Quantum.com); Dennis Appleyard;
T10 org
Subject: Re: Saveable mode pages
It is interesting that SPC-4 promises behavior of FORMAT UNIT command when
FORMAT UNIT command is not included in SPC-4 and there isn't even a "see
command standard" reference. I think you would be happier with a statement
like "Saveable mode pages may also be saved by a FORMAT UNIT command (see
SBC-4 and SSC-x)". i guess we missed this during letter ballot review last
year.
On Wed, Feb 11, 2015 at 4:02 PM, Kevin D Butt
<kdbutt at us.ibm.com> wrote:
I am confused by 6.12.5 Saved values
<<All saveable mode pages should be considered saved if a MODE SELECT command
issued with the SP bit set to one has completed with a GOOD status or after
the successful completion of a FORMAT UNIT command.>>
This states that after the successful completion of a FORMAT UNIT command ALL
saveable mode pages should be considered saved. This may be good for block
devices, but why are tape devices included in this? On tape devices a FORMAT
UNIT command formats the tape but does not change other things in the device
- nor do we want it to.  Also, I can interpret this to say, when doing a
FORMAT UNIT command part of the processing is to take all the Current values
of mode pages that are saveable and save them. This may violate the intent of
the application client which explicitly did not set the SP bit in the MODE
SELECT that updated the Current values (and explicitly did not update them to
Saved values).
Is anybody else bothered by this?
Kevin D. Butt
SCSI Architect, Tape Firmware, CAMSS
T10 Standards
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280<tel:520-799-5280>
Fax: 520-799-2723<tel:520-799-2723> (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/


From lohmeyer at t10.org  Sat Feb 14 23:04:43 2015
From: lohmeyer at t10.org (T10 Administrator)
Date: Sun, 15 Feb 2015 02:04:43 -0500
Subject: Recent T10 documents uploaded since 2015/02/08
Message-ID: <mailman.79.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC-4 Per IO Advice (hints)
(by: Frederick Knight)
T10/14-065r2   Uploaded: 2015/02/12   281841 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-065r2.pdf
SPC-5: Combined BIND/UNBIND/Rebind
(by: Frederick Knight)
T10/14-146r7   Uploaded: 2015/02/10   228353 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-146r7.pdf
Working Drafts
--------------
(Report generated on 2015/02/15 at 00:04:17)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Mon Feb 16 18:52:06 2015
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Tue, 17 Feb 2015 02:52:06 +0000
Subject: Tomorrows BIND con-call cancelled
Message-ID: <mailman.80.1441607016.22458.t10@sandbox.t10.org>

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1502160_nameless-2480-2-1.html">nameless-2480-2-1.html</a>

On the last call, we finished the document.  I haven't had time to spin a new
revision yet, so we're cancelling tomorrows con-call.
		Fred Knight


From Frederick.Knight at netapp.com  Mon Feb 16 19:09:02 2015
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Tue, 17 Feb 2015 03:09:02 +0000
Subject: Canceled: T10 Conglomerates BIND con-call (Feb 17)
Message-ID: <mailman.81.1441607016.22458.t10@sandbox.t10.org>

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



From lohmeyer at t10.org  Wed Feb 18 09:37:23 2015
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 18 Feb 2015 10:37:23 -0700
Subject: DIS 14776-262 (SPL-2)
Message-ID: <mailman.82.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
T10 members,
I have added an agenda item to the March 12 T10 agenda to vote on 
recommending approval of DIS 14776-262 (SPL-2). This document is covered 
by an ISO/IEC copyright. If you are a voting member of T10 and wish to 
review this document prior to the meeting, please let me know and I will 
send you a copy of the pdf file.
John
*
* 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 Feb 18 11:14:37 2015
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Wed, 18 Feb 2015 19:14:37 +0000
Subject: Request for added additional sense codes to support ZBC
 implementations
Message-ID: <mailman.83.1441607016.22458.t10@sandbox.t10.org>

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1502181_nameless-2872-2-1.html">nameless-2872-2-1.html</a>

Like a handful of prestigious organizations before us, Western Digital
engineers see value in being able to communicate "interesting" ZBC error
conditions with unique additional sense codes. To this end, WD is proposing
the re-purposing of one additional sense code plus the addition two new ASCQ
values.
Details can be found in:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-065r0.pdf
All the best,
.Ralph


From Ralph.Weber at wdc.com  Wed Feb 18 11:43:23 2015
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Wed, 18 Feb 2015 19:43:23 +0000
Subject: Security Features for SCSI Commands (SFSC) proposal posted
Message-ID: <mailman.84.1441607016.22458.t10@sandbox.t10.org>

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

The only proposal known to me for changes SFSC has been posted.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-064r0.pdf
The objective is to align SFSC with the newest IETF security RFCs (and update
the references accordingly). Speed reading through 15-064r0 will provide
quick proof that not much work needs to be done.
WARNING: Unless whatever SFSC changes are out there become known to T10 soon,
I will begin lobbying for an SFSC letter ballot shortly after 15-064 is
approved.
All the best,
.Ralph


From munjal_mistry at mentor.com  Thu Feb 19 03:18:28 2015
From: munjal_mistry at mentor.com (Munjal Mistry)
Date: Thu, 19 Feb 2015 16:48:28 +0530
Subject: Query regarding response of UNMAP command
Message-ID: <mailman.85.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Munjal Mistry <munjal_mistry at mentor.com>
*
Hi,
I have a query regarding the response for UNMAP command when there is 
mismatch of "PARAMETER LIST LENGTH" (field of UNMAP command) with "UNMAP 
DATA LENGTH" or "UNMAP BLOCK DESCRIPTOR DATA LENGTH" (fields of unmap 
parameter list).  Here, Storage device is thin provisioning.
For example, host wants to transfer single block descriptor with UNMAP 
command. In this cases following values shall be driven:
PARAMETER LIST LENGTH= 'h18 (24),
UNMAP DATA LENGTH= 'h16 (22),
UNMAP BLOCK DESCRIPTOR DATA LENGTH= 'h10 (16).
Here, if host transmits other than 'h16 value for UNMAP DATA LENGTH 
field or other than 'h10 for UNMAP BLOCK DESCRIPTOR DATA LENGTH field, 
then which of the following behavior of device is correct:
(1) Device ignores it's value and unmap the logical blocks described 
with UNMAP block descriptor and sends GOOD response.
(2) Device ignores it's value and unmap the logical blocks described 
with UNMAP block descriptor and sends failure response.
(3) Device terminates the command and sends failure response.
If device sends the failure response, as per the 2nd and 3rd behavior 
then what would be the possible status, ASC and ASCQ for failure?
-- 
Warm Regards,
Munjal Mistry
*
* 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 Feb 19 06:55:36 2015
From: david.black at emc.com (Black, David)
Date: Thu, 19 Feb 2015 14:55:36 +0000
Subject: Query regarding response of UNMAP command
Message-ID: <mailman.86.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Black, David" <david.black at emc.com>
*
In general, truncated UNMAP block descriptors are ignored.
> For example, host wants to transfer single block descriptor with UNMAP
> command. In this cases following values shall be driven:
> PARAMETER LIST LENGTH= 'h18 (24),
> UNMAP DATA LENGTH= 'h16 (22),
> UNMAP BLOCK DESCRIPTOR DATA LENGTH= 'h10 (16).
> 
> Here, if host transmits other than 'h16 value for UNMAP DATA LENGTH
> field or other than 'h10 for UNMAP BLOCK DESCRIPTOR DATA LENGTH field,
> then which of the following behavior of device is correct:
There's no single answer.
If those values are smaller than stated above, and are consistent,
the UNMAP block descriptor is incomplete and is ignored; nothing happens
and GOOD status is returned.
If those values are larger than stated above, and are consistent, then the
PARAMETER LIST LENGTH in the CDB truncated the parameter data; the one
complete UNMAP block descriptor that was received is processed and the
truncation is not an error.
If those two values are inconsistent, the shortest one governs whether
a complete UNMAP block descriptor was received, and it's ok to proceed
as above.  It's probably a better idea to note the inconsistency (especially
if UNMAP DATA LENGTH is too small by comparison to UNMAP BLOCK DESCRIPTOR
LENGTH) and treat that as an error -
CHECK CONDITION, ILLEGAL REQUEST, INVALID VALUE IN PARAMETER LIST.
Thanks,
--David
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Munjal
Mistry
> Sent: Thursday, February 19, 2015 6:18 AM
> To: T10 Reflector
> Subject: Query regarding response of UNMAP command
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Munjal Mistry <munjal_mistry at mentor.com>
> *
> Hi,
> 
> I have a query regarding the response for UNMAP command when there is
> mismatch of "PARAMETER LIST LENGTH" (field of UNMAP command) with "UNMAP
> DATA LENGTH" or "UNMAP BLOCK DESCRIPTOR DATA LENGTH" (fields of unmap
> parameter list).  Here, Storage device is thin provisioning.
> 
> For example, host wants to transfer single block descriptor with UNMAP
> command. In this cases following values shall be driven:
> PARAMETER LIST LENGTH= 'h18 (24),
> UNMAP DATA LENGTH= 'h16 (22),
> UNMAP BLOCK DESCRIPTOR DATA LENGTH= 'h10 (16).
> 
> Here, if host transmits other than 'h16 value for UNMAP DATA LENGTH
> field or other than 'h10 for UNMAP BLOCK DESCRIPTOR DATA LENGTH field,
> then which of the following behavior of device is correct:
> 
> (1) Device ignores it's value and unmap the logical blocks described
> with UNMAP block descriptor and sends GOOD response.
> (2) Device ignores it's value and unmap the logical blocks described
> with UNMAP block descriptor and sends failure response.
> (3) Device terminates the command and sends failure response.
> 
> If device sends the failure response, as per the 2nd and 3rd behavior
> then what would be the possible status, ASC and ASCQ for failure?
> 
> 
> --
> Warm Regards,
> Munjal Mistry
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gerry.houlder at seagate.com  Thu Feb 19 08:08:11 2015
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Thu, 19 Feb 2015 10:08:11 -0600
Subject: Query regarding response of UNMAP command
Message-ID: <mailman.87.1441607016.22458.t10@sandbox.t10.org>

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

I am disappointed that the SBC-4 standards doesn't require the UNMAP DATA
LENGTH to be equal to the PARAMETER LIST LENGTH minus two. Similar
instances in other commands call out the CHECK CONDITION response described
by David Black in his earlier email.
I am also disappointed that the standard only says "should" on the UNMAP
DESCRIPTOR LENGTH have to be an exact multiple of the number of unmap block
descriptors. If I were implementing the UNMAP command in a storage device I
would reject any command that doesn't have an exact multiple with ILLEGAL
REQUEST. i think the idea of letting the target device ignore an incomplete
block descriptor has high risk of doing the wrong thing. For instance, the
"shortened bytes" might be the first bytes of the first descriptor instead
of the last bytes of the last descriptor. If this were the case then all of
the descriptors would be incorrectly framed, the target would unmap the
wrong LBAs (possible loss of customer data), and the command would end with
GOOD status (the host would never know that he screwed up). A safer way to
handle this is to ignore all of the unmap block descriptors if the list
length isn't an exact match for an appropriate list.
If all of the lengths do match but the number of data bytes transferred is
not an exact match for the PARAMETER LIST LENGTH, the the underlying
protocol (e.g., SAS protocol layer) would detect a data underrun or data
overrun. This would result in a response packet (for SAS) that indicates
the error. This procedure will vary depending on how your particular
protocol layer handles data underrun and overrun situations.
On Thu, Feb 19, 2015 at 8:55 AM, 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>
> *
> In general, truncated UNMAP block descriptors are ignored.
>
> > For example, host wants to transfer single block descriptor with UNMAP
> > command. In this cases following values shall be driven:
> > PARAMETER LIST LENGTH= 'h18 (24),
> > UNMAP DATA LENGTH= 'h16 (22),
> > UNMAP BLOCK DESCRIPTOR DATA LENGTH= 'h10 (16).
> >
> > Here, if host transmits other than 'h16 value for UNMAP DATA LENGTH
> > field or other than 'h10 for UNMAP BLOCK DESCRIPTOR DATA LENGTH field,
> > then which of the following behavior of device is correct:
>
> There's no single answer.
>
> If those values are smaller than stated above, and are consistent,
> the UNMAP block descriptor is incomplete and is ignored; nothing happens
> and GOOD status is returned.
>
> If those values are larger than stated above, and are consistent, then the
> PARAMETER LIST LENGTH in the CDB truncated the parameter data; the one
> complete UNMAP block descriptor that was received is processed and the
> truncation is not an error.
>
> If those two values are inconsistent, the shortest one governs whether
> a complete UNMAP block descriptor was received, and it's ok to proceed
> as above.  It's probably a better idea to note the inconsistency
> (especially
> if UNMAP DATA LENGTH is too small by comparison to UNMAP BLOCK DESCRIPTOR
> LENGTH) and treat that as an error -
> CHECK CONDITION, ILLEGAL REQUEST, INVALID VALUE IN PARAMETER LIST.
>
> Thanks,
> --David
>
> > -----Original Message-----
> > From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Munjal
> Mistry
> > Sent: Thursday, February 19, 2015 6:18 AM
> > To: T10 Reflector
> > Subject: Query regarding response of UNMAP command
> >
> > * From the T10 Reflector (t10 at t10.org), posted by:
> > * Munjal Mistry <munjal_mistry at mentor.com>
> > *
> > Hi,
> >
> > I have a query regarding the response for UNMAP command when there is
> > mismatch of "PARAMETER LIST LENGTH" (field of UNMAP command) with "UNMAP
> > DATA LENGTH" or "UNMAP BLOCK DESCRIPTOR DATA LENGTH" (fields of unmap
> > parameter list).  Here, Storage device is thin provisioning.
> >
> > For example, host wants to transfer single block descriptor with UNMAP
> > command. In this cases following values shall be driven:
> > PARAMETER LIST LENGTH= 'h18 (24),
> > UNMAP DATA LENGTH= 'h16 (22),
> > UNMAP BLOCK DESCRIPTOR DATA LENGTH= 'h10 (16).
> >
> > Here, if host transmits other than 'h16 value for UNMAP DATA LENGTH
> > field or other than 'h10 for UNMAP BLOCK DESCRIPTOR DATA LENGTH field,
> > then which of the following behavior of device is correct:
> >
> > (1) Device ignores it's value and unmap the logical blocks described
> > with UNMAP block descriptor and sends GOOD response.
> > (2) Device ignores it's value and unmap the logical blocks described
> > with UNMAP block descriptor and sends failure response.
> > (3) Device terminates the command and sends failure response.
> >
> > If device sends the failure response, as per the 2nd and 3rd behavior
> > then what would be the possible status, ASC and ASCQ for failure?
> >
> >
> > --
> > Warm Regards,
> > Munjal Mistry
> >
> > *
> > * 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 phughes at solidfire.com  Thu Feb 19 09:46:58 2015
From: phughes at solidfire.com (Paul Hughes)
Date: Thu, 19 Feb 2015 10:46:58 -0700
Subject: Query regarding response of UNMAP command
Message-ID: <mailman.88.1441607016.22458.t10@sandbox.t10.org>

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

I agree, but SBC allows initiators to send commands that don't make much
sense (e.g. READ or WRITE with Transfer Length of zero blocks) which makes
you wonder whether the initiator is confused. On the other hand SPC has
examples of commands that require parameter data to match a certain size
(e.g. MODE SELECT, PERSISTENT RESERVE OUT).
On Thu, Feb 19, 2015 at 9:08 AM, Gerry Houlder <gerry.houlder at seagate.com>
wrote:
> I am disappointed that the SBC-4 standards doesn't require the UNMAP DATA
> LENGTH to be equal to the PARAMETER LIST LENGTH minus two. Similar
> instances in other commands call out the CHECK CONDITION response described
> by David Black in his earlier email.
>
> I am also disappointed that the standard only says "should" on the UNMAP
> DESCRIPTOR LENGTH have to be an exact multiple of the number of unmap block
> descriptors. If I were implementing the UNMAP command in a storage device I
> would reject any command that doesn't have an exact multiple with ILLEGAL
> REQUEST. i think the idea of letting the target device ignore an incomplete
> block descriptor has high risk of doing the wrong thing. For instance, the
> "shortened bytes" might be the first bytes of the first descriptor instead
> of the last bytes of the last descriptor. If this were the case then all of
> the descriptors would be incorrectly framed, the target would unmap the
> wrong LBAs (possible loss of customer data), and the command would end with
> GOOD status (the host would never know that he screwed up). A safer way to
> handle this is to ignore all of the unmap block descriptors if the list
> length isn't an exact match for an appropriate list.
>
> If all of the lengths do match but the number of data bytes transferred is
> not an exact match for the PARAMETER LIST LENGTH, the the underlying
> protocol (e.g., SAS protocol layer) would detect a data underrun or data
> overrun. This would result in a response packet (for SAS) that indicates
> the error. This procedure will vary depending on how your particular
> protocol layer handles data underrun and overrun situations.
>
> On Thu, Feb 19, 2015 at 8:55 AM, 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>
>> *
>> In general, truncated UNMAP block descriptors are ignored.
>>
>> > For example, host wants to transfer single block descriptor with UNMAP
>> > command. In this cases following values shall be driven:
>> > PARAMETER LIST LENGTH= 'h18 (24),
>> > UNMAP DATA LENGTH= 'h16 (22),
>> > UNMAP BLOCK DESCRIPTOR DATA LENGTH= 'h10 (16).
>> >
>> > Here, if host transmits other than 'h16 value for UNMAP DATA LENGTH
>> > field or other than 'h10 for UNMAP BLOCK DESCRIPTOR DATA LENGTH field,
>> > then which of the following behavior of device is correct:
>>
>> There's no single answer.
>>
>> If those values are smaller than stated above, and are consistent,
>> the UNMAP block descriptor is incomplete and is ignored; nothing happens
>> and GOOD status is returned.
>>
>> If those values are larger than stated above, and are consistent, then the
>> PARAMETER LIST LENGTH in the CDB truncated the parameter data; the one
>> complete UNMAP block descriptor that was received is processed and the
>> truncation is not an error.
>>
>> If those two values are inconsistent, the shortest one governs whether
>> a complete UNMAP block descriptor was received, and it's ok to proceed
>> as above.  It's probably a better idea to note the inconsistency
>> (especially
>> if UNMAP DATA LENGTH is too small by comparison to UNMAP BLOCK DESCRIPTOR
>> LENGTH) and treat that as an error -
>> CHECK CONDITION, ILLEGAL REQUEST, INVALID VALUE IN PARAMETER LIST.
>>
>> Thanks,
>> --David
>>
>> > -----Original Message-----
>> > From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Munjal
>> Mistry
>> > Sent: Thursday, February 19, 2015 6:18 AM
>> > To: T10 Reflector
>> > Subject: Query regarding response of UNMAP command
>> >
>> > * From the T10 Reflector (t10 at t10.org), posted by:
>> > * Munjal Mistry <munjal_mistry at mentor.com>
>> > *
>> > Hi,
>> >
>> > I have a query regarding the response for UNMAP command when there is
>> > mismatch of "PARAMETER LIST LENGTH" (field of UNMAP command) with "UNMAP
>> > DATA LENGTH" or "UNMAP BLOCK DESCRIPTOR DATA LENGTH" (fields of unmap
>> > parameter list).  Here, Storage device is thin provisioning.
>> >
>> > For example, host wants to transfer single block descriptor with UNMAP
>> > command. In this cases following values shall be driven:
>> > PARAMETER LIST LENGTH= 'h18 (24),
>> > UNMAP DATA LENGTH= 'h16 (22),
>> > UNMAP BLOCK DESCRIPTOR DATA LENGTH= 'h10 (16).
>> >
>> > Here, if host transmits other than 'h16 value for UNMAP DATA LENGTH
>> > field or other than 'h10 for UNMAP BLOCK DESCRIPTOR DATA LENGTH field,
>> > then which of the following behavior of device is correct:
>> >
>> > (1) Device ignores it's value and unmap the logical blocks described
>> > with UNMAP block descriptor and sends GOOD response.
>> > (2) Device ignores it's value and unmap the logical blocks described
>> > with UNMAP block descriptor and sends failure response.
>> > (3) Device terminates the command and sends failure response.
>> >
>> > If device sends the failure response, as per the 2nd and 3rd behavior
>> > then what would be the possible status, ASC and ASCQ for failure?
>> >
>> >
>> > --
>> > Warm Regards,
>> > Munjal Mistry
>> >
>> > *
>> > * 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
>>
>
>
-- 
*Paul HughesSenior Software Engineer, SolidFire, Inc.*
e: phughes at solidfire.com
*Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play&gt;**???*


From lohmeyer at t10.org  Sat Feb 21 23:04:33 2015
From: lohmeyer at t10.org (T10 Administrator)
Date: Sun, 22 Feb 2015 02:04:33 -0500
Subject: Recent T10 documents uploaded since 2015/02/15
Message-ID: <mailman.89.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPL-4 Active Transmitter Adjustment
(by: Tim Symons)
T10/14-077r6   Uploaded: 2015/02/20   616706 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-077r6.pdf
SPL-4: 128b130b Coding
(by: George Penokie)
T10/15-029r1   Uploaded: 2015/02/18   569940 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-029r1.pdf
SPL-4: Forward Error Correction
(by: Bill Voorhees)
T10/15-032r1   Uploaded: 2015/02/19   160441 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-032r1.pdf
Align SFSC with RFC 7296 (newest IKEv2)
(by: Ralph Weber)
T10/15-064r0   Uploaded: 2015/02/18   173194 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-064r0.pdf
SPC-5: More Additional Sense Codes for Zoned Devices
(by: Ralph Weber)
T10/15-065r0   Uploaded: 2015/02/18   76403 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-065r0.pdf
SPL-4: Binary Primitive Encodings
(by: Bill Voorhees)
T10/15-066r0   Uploaded: 2015/02/19   613536 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-066r0.pdf
SPL-4: Binary Primitive Encodings
(by: Bill Voorhees)
T10/15-066r0   Uploaded: 2015/02/19   13073 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-066r0.zip
Working Drafts
--------------
(Report generated on 2015/02/22 at 00:03:54)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From munjal_mistry at mentor.com  Mon Feb 23 23:41:58 2015
From: munjal_mistry at mentor.com (Munjal Mistry)
Date: Tue, 24 Feb 2015 13:11:58 +0530
Subject: Query regarding response of MODE SENSE10 command
Message-ID: <mailman.90.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Munjal Mistry <munjal_mistry at mentor.com>
*
Hi,
I have a query regarding mode page transfer with MODE SENSE 10 command 
with PC=01b.
As per the SPC-4 specification (Topic-6.13.3 Changeable values), device 
returns a mask denoting those mode parameters that are changeable i.e. 
other than changeable parameter's value shall be set to 0.
Here, my confusion is about the value of first 2 bytes of mode pages 
which indicates {PS, SPF, PAGE CODE} in 1st byte and {PAGE LENGTH} in 
2nd byte. Will it be driven 0 (as it can't be changed) or it's actual 
value will be driven with PC=01b?
Similarly, for mode parameter header, what could be the value of {MODE 
DATA LENGTH} field?
Thank you.
-- 
Warm Regards,
Munjal Mistry
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gerry.houlder at seagate.com  Tue Feb 24 07:05:08 2015
From: gerry.houlder at seagate.com (Gerry Houlder)
Date: Tue, 24 Feb 2015 09:05:08 -0600
Subject: Query regarding response of MODE SENSE10 command
Message-ID: <mailman.91.1441607016.22458.t10@sandbox.t10.org>

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

The "changeable values" only apply to parameter bytes within a mode page.
The contents of the Mode Parameter header, Block Descriptor (if any), and
the first few bytes of each mode page (the Page Code, Subpage Code, Page
Length, PS bit, and SPF bit) are the same for all values of the PC field.
On Tue, Feb 24, 2015 at 1:41 AM, Munjal Mistry <munjal_mistry at mentor.com>
wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Munjal Mistry <munjal_mistry at mentor.com>
> *
> Hi,
>
> I have a query regarding mode page transfer with MODE SENSE 10 command
> with PC=01b.
>
> As per the SPC-4 specification (Topic-6.13.3 Changeable values), device
> returns a mask denoting those mode parameters that are changeable i.e.
> other than changeable parameter's value shall be set to 0.
>
> Here, my confusion is about the value of first 2 bytes of mode pages which
> indicates {PS, SPF, PAGE CODE} in 1st byte and {PAGE LENGTH} in 2nd byte.
> Will it be driven 0 (as it can't be changed) or it's actual value will be
> driven with PC=01b?
>
> Similarly, for mode parameter header, what could be the value of {MODE
> DATA LENGTH} field?
>
> Thank you.
>
> --
> Warm Regards,
> Munjal Mistry
>
> *
> * 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  Tue Feb 24 09:24:07 2015
From: Ralph.Weber at wdc.com (Ralph Weber)
Date: Tue, 24 Feb 2015 17:24:07 +0000
Subject: SAM-5 Letter Ballot results
Message-ID: <mailman.92.1441607016.22458.t10@sandbox.t10.org>

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

The SAM-5 Letter Ballot passed 23:3:0:3=29.
Comments were received from eight organizations.
T10 members of record with INCITS can access the comment at:
https://standards.incits.org/apps/org/workgroup/t10/documents.php?folder_id=1
452
All the best,
.Ralph


From bill.martin at ssi.samsung.com  Wed Feb 25 15:21:33 2015
From: bill.martin at ssi.samsung.com (Bill Martin-SSI)
Date: Wed, 25 Feb 2015 23:21:33 +0000
Subject: FW: Re: T10 Document Number Assigned (T10/14-275r5)
Message-ID: <mailman.93.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill Martin-SSI <bill.martin at ssi.samsung.com>
*
An updated 14-275r5 has been posted. This version removes the ability to
reduce the over provisioning area. I am hopeful of getting a vote on this
proposal at the next T10 meeting.
Bill Martin
SSD I/O Standards 
Samsung Semiconductor, Inc. 
Cell (408) 499-1839
-----Original Message-----
From: T10 Document Administrator [mailto:lohmeyer at t10.org] 
Sent: Wednesday, February 25, 2015 2:49 PM
To: Bill Martin-SSI
Subject: Re: Re: T10 Document Number Assigned (T10/14-275r5)
2015/02/25 15:48:06 
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=14-275r5.pdf
Normally, the posting/archiving process takes about 30 minutes.
Please contact John Lohmeyer <lohmeyer at t10.org> should you need further
assistance.
bill.martin at ssi.samsung.com wrote: 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Sat Feb 28 23:05:50 2015
From: lohmeyer at t10.org (T10 Administrator)
Date: Sun, 1 Mar 2015 02:05:50 -0500
Subject: Recent T10 documents uploaded since 2015/02/22
Message-ID: <mailman.94.1441607016.22458.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC4: Storage Intelligence
(by: William Martin)
T10/14-275r5   Uploaded: 2015/02/25   433354 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-275r5.pdf
ZBC Low power condition fixes
(by: Gerald Houlder)
T10/15-006r1   Uploaded: 2015/02/26   29540 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-006r1.pdf
NWIP-SPL-3
(by: Gary Robinson)
T10/15-045r1   Uploaded: 2015/02/23   56823 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-045r1.pdf
Results of Letter Ballot on forwarding SAM-5 to First Public Review
(by: Ralph Weber)
T10/15-059r0   Uploaded: 2015/02/24   91438 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-059r0.pdf
INCITS LB eb-2015-00122 - Appointment of Mr. Ralph Weber as the
Chairman of T10
(by: Jennifer Garner)
T10/15-067r0   Uploaded: 2015/02/25   47575 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-067r0.pdf
Letter Ballot Jeopardy - February 25, 2015
(by: John Lohmeyer)
T10/15-068r0   Uploaded: 2015/02/25   29063 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-068r0.pdf
SAM-5 Letter Ballot Comments Resolutions
(by: George Penokie)
T10/15-069r0   Uploaded: 2015/02/25   960802 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-069r0.fdf
SAM-5 Letter Ballot Comments Resolutions
(by: George Penokie)
T10/15-069r0   Uploaded: 2015/02/25   3455135 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-069r0.pdf
Meeting Announcement: T10 Week Jul 13-17, 2015 -- Vancouver, BC
(by: Tim Symons)
T10/15-073r0   Uploaded: 2015/02/26   111162 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-073r0.pdf
ZBC Add sense data response when transition to FULL
(by: Gerald Houlder)
T10/15-074r0   Uploaded: 2015/02/27   28924 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-074r0.pdf
SBC-4 SPC-5 Obsolete READ LONG and WRITE LONG except for write
uncorrectable
(by: Gerald Houlder)
T10/15-075r0   Uploaded: 2015/02/27   110255 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-075r0.pdf
ADC-4 List of potential issues to resolve
(by: Kevin Butt)
T10/15-076r0   Uploaded: 2015/02/27   17785 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-076r0.fdf
ADT-3 List of potential issues to resolve
(by: Kevin Butt)
T10/15-077r0   Uploaded: 2015/02/27   154952 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-077r0.fdf
Working Drafts
--------------
(Report generated on 2015/03/01 at 00:05:01)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org