From kdbutt at us.ibm.com  Thu Oct  1 12:45:51 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 1 Oct 2009 12:45:51 -0700
Subject: SSC-4: Programmable Early Warning question
Message-ID: <mailman.627.1441607350.22516.t10@sandbox.t10.org>

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

Tapeheads,
I wonder if we should protect the programmable early warning from being 
set to too large a value.  Should we add some statement like the following 
to SSC-4?
If PEWS field of Device Configuration Extension mode page is set to a 
value larger than the tapes capacity, then the Mode Select should be 
rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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 Payne_Robert at emc.com  Thu Oct  1 13:45:37 2009
From: Payne_Robert at emc.com (Payne_Robert at emc.com)
Date: Thu, 1 Oct 2009 16:45:37 -0400
Subject: Read Buffer mode 03h
Message-ID: <mailman.628.1441607350.22516.t10@sandbox.t10.org>

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

Section 6.15.5 of SPC-3 included the following:
"If there is no buffer associated with the specified buffer ID, the
device server shall return all zeros in the READ BUFFER descriptor."
I recently noticed that the current draft of SPC-4 does not include this
text.  
I am looking for background information on why this text is missing from
SPC-4.
Best Regards,
Robert Payne
Senior Software Engineer
Global Platform Software
EMC


From curtis.ballard at hp.com  Thu Oct  1 15:21:49 2009
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Thu, 1 Oct 2009 22:21:49 +0000
Subject: SSC-4: Programmable Early Warning question
Message-ID: <mailman.629.1441607350.22516.t10@sandbox.t10.org>

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

In the interest of having a complete specification it would be appropriate to
specify behavior although I would hope that an application would never make
that mistake.
Rather than reject the command I would be inclined to have a device specific
maximum PEWS zone and report a recovered error with the PEWS zone set to the
maximum allowed.
Curtis Ballard
Hewlett Packard
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
Sent: Thursday, October 01, 2009 1:46 PM
To: t10 at t10.org
Subject: SSC-4: Programmable Early Warning question
Tapeheads,
I wonder if we should protect the programmable early warning from being set
to too large a value.  Should we add some statement like the following to
SSC-4?
If PEWS field of Device Configuration Extension mode page is set to a value
larger than the tapes capacity, then the Mode Select should be rejected with
ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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 tjmac at tolisgroup.com  Thu Oct  1 16:12:44 2009
From: tjmac at tolisgroup.com (Tim Jones)
Date: Thu, 1 Oct 2009 16:12:44 -0700
Subject: SSC-4: Programmable Early Warning question
Message-ID: <mailman.630.1441607350.22516.t10@sandbox.t10.org>

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

As a software developer, I tend to agree Curtis' comment and would  
add that a PEWS zone defined larger than some mutually agreed upon  
percentage of the total, uncompressed capacity of a given tape (since  
most technologies support more than a single tape capacity for	
writes) be the deciding factor for the "too large" of a value being  
supplied.
Tim
On Oct 1, 2009, at 3:21 PM, Ballard, Curtis C (StorageWorks) wrote:
> In the interest of having a complete specification it would be  
> appropriate to specify behavior although I would hope that an  
> application would never make that mistake.
>
> Rather than reject the command I would be inclined to have a device  
> specific maximum PEWS zone and report a recovered error with the  
> PEWS zone set to the maximum allowed.
>
> Curtis Ballard
> Hewlett Packard
>
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of  
> Kevin D Butt
> Sent: Thursday, October 01, 2009 1:46 PM
> To: t10 at t10.org
> Subject: SSC-4: Programmable Early Warning question
>
>
> Tapeheads,
>
> I wonder if we should protect the programmable early warning from  
> being set to too large a value.  Should we add some statement like  
> the following to SSC-4?
>
> If PEWS field of Device Configuration Extension mode page is set to  
> a value larger than the tapes capacity, then the Mode Select should  
> be rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/


From kdbutt at us.ibm.com  Thu Oct  1 17:21:01 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 1 Oct 2009 17:21:01 -0700
Subject: SSC-4: Programmable Early Warning question
Message-ID: <mailman.631.1441607350.22516.t10@sandbox.t10.org>

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

Curtis,
Yes, parameters rounded would be better and more consistent with mode 
pages.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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:
"Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
To:
Kevin D Butt/Tucson/IBM at IBMUS, "t10 at t10.org" <t10 at t10.org>
Date:
10/01/2009 03:23 PM
Subject:
RE: SSC-4: Programmable Early Warning question
In the interest of having a complete specification it would be appropriate 
to specify behavior although I would hope that an application would never 
make that mistake.
Rather than reject the command I would be inclined to have a device 
specific maximum PEWS zone and report a recovered error with the PEWS zone 
set to the maximum allowed.
Curtis Ballard
Hewlett Packard
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Thursday, October 01, 2009 1:46 PM
To: t10 at t10.org
Subject: SSC-4: Programmable Early Warning question
Tapeheads, 
I wonder if we should protect the programmable early warning from being 
set to too large a value.  Should we add some statement like the following 
to SSC-4? 
If PEWS field of Device Configuration Extension mode page is set to a 
value larger than the tapes capacity, then the Mode Select should be 
rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 


From kdbutt at us.ibm.com  Thu Oct  1 20:30:56 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 1 Oct 2009 20:30:56 -0700
Subject: SSC-4: Append-only mode proposal has been updated (09-356r2)
Message-ID: <mailman.632.1441607350.22516.t10@sandbox.t10.org>

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

I have updated the append-only proposal  with some feedback from Paul 
Suhler and internal reviewers.
2009/10/01 20:32:17 
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=09-356r2.pdf
Normally, the posting/archiving process takes about 30 minutes.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:
Kevin D Butt/Tucson/IBM at IBMUS
To:
t10 at t10.org
Date:
09/30/2009 05:30 PM
Subject:
SSC-4: Append-only mode proposal has been uploaded
Tapeheads, 
I have uploaded a proposal related to protecting data.	I would appreciate 
any feedback you might have and will attempt to make any suggested changes 
prior to Nov meeting. 
2009/09/30 17:36:14 
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=09-356r1.pdf
Normally, the posting/archiving process takes about 30 minutes.
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 


From dennis at hale-pohaku.net  Thu Oct  1 17:15:52 2009
From: dennis at hale-pohaku.net (Dennis Painter)
Date: Thu, 01 Oct 2009 14:15:52 -1000
Subject: SSC-4: Programmable Early Warning question
Message-ID: <mailman.633.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Dennis Painter <dennis at hale-pohaku.net>
*
Protection from it being set to a value greater that the media capacity 
is good. I favor recovered error as the software can accept it and 
continue or has the option to read the PEWS setting.
Is it allowed for the application client to set PEWS if there is no 
media present? I did not find a restriction in the current draft but it 
may not be where I looked.
If not restricted and media of different capacity is supported then 
there is a potential problem of PEWS being set for a larger capacity 
tape and having a smaller capacity tape inserted. If PEWS is cleared on 
media removal and cannot be set without media present then there would 
be no issue.
Dennis Painter
Ballard, Curtis C (StorageWorks) wrote:
> In the interest of having a complete specification it would be 
> appropriate to specify behavior although I would hope that an 
> application would never make that mistake.
>  
> Rather than reject the command I would be inclined to have a device 
> specific maximum PEWS zone and report a recovered error with the PEWS 
> zone set to the maximum allowed.
>  
> Curtis Ballard
> Hewlett Packard
>
> ------------------------------------------------------------------------
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of 
> *Kevin D Butt
> *Sent:* Thursday, October 01, 2009 1:46 PM
> *To:* t10 at t10.org
> *Subject:* SSC-4: Programmable Early Warning question
>
>
> Tapeheads,
>
> I wonder if we should protect the programmable early warning from 
> being set to too large a value.  Should we add some statement like the 
> following to SSC-4?
>
> If PEWS field of Device Configuration Extension mode page is set to a 
> value larger than the tapes capacity, then the Mode Select should be 
> rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> 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/ 
--------------050506040709020403060503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Protection from it being set to a value greater that the media capacity is
good. I favor recovered error as the software can accept it and continue or
has the option to read the PEWS setting.
Is it allowed for the application client to set PEWS if there is no media
present? I did not find a restriction in the current draft but it may not be
where I looked.
If not restricted and media of different capacity is supported then there is
a potential problem of PEWS being set for a larger capacity tape and having a
smaller capacity tape inserted. If PEWS is cleared on media removal and
cannot be set without media present then there would be no issue.
Dennis Painter
Ballard, Curtis C (StorageWorks) wrote: 
>In the interest of having a complete specification it would be appropriate
to specify behavior although I would hope that an application would never
make that mistake.
> 
>Rather than reject the command I would be inclined to have a device specific
maximum PEWS zone and report a recovered error with the PEWS zone set to the
maximum allowed.
> 
>Curtis Ballard
>Hewlett Packard
>
>
>----------
>From: <mailto:owner-t10 at t10.org>owner-t10 at t10.org [mailto:owner-t10 at t10.org]
On Behalf Of Kevin D Butt
>Sent: Thursday, October 01, 2009 1:46 PM
>To: <mailto:t10 at t10.org>t10 at t10.org
>Subject: SSC-4: Programmable Early Warning question
>
>
>Tapeheads, 
>
>I wonder if we should protect the programmable early warning from being set
to too large a value.  Should we add some statement like the following to
SSC-4? 
>
>If PEWS field of Device Configuration Extension mode page is set to a value
larger than the tapes capacity, then the Mode Select should be rejected with
ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST. 
>
>Thanks, 
>
>Kevin D. Butt
>SCSI & Fibre Channel Architect, Tape Firmware
>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/ 
--------------050506040709020403060503--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Fri Oct  2 09:12:57 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 2 Oct 2009 09:12:57 -0700
Subject: SSC-4: Programmable Early Warning question
Message-ID: <mailman.634.1441607350.22516.t10@sandbox.t10.org>

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

How about adding this sentence?
 If the PEWS field is set to a value larger than supported, the device 
server shall round the value to its maximum supported value and shall 
return CHECK CONDITION status, with the sense key set to RECOVERED ERROR, 
and the additional sense code set to ROUNDED PARAMETER.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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:
Kevin D Butt/Tucson/IBM at IBMUS
To:
"Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
Cc:
"t10 at t10.org" <t10 at t10.org>
Date:
10/01/2009 06:08 PM
Subject:
RE: SSC-4: Programmable Early Warning question
Curtis, 
Yes, parameters rounded would be better and more consistent with mode 
pages. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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: 
"Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com> 
To: 
Kevin D Butt/Tucson/IBM at IBMUS, "t10 at t10.org" <t10 at t10.org> 
Date: 
10/01/2009 03:23 PM 
Subject: 
RE: SSC-4: Programmable Early Warning question
In the interest of having a complete specification it would be appropriate 
to specify behavior although I would hope that an application would never 
make that mistake. 
Rather than reject the command I would be inclined to have a device 
specific maximum PEWS zone and report a recovered error with the PEWS zone 
set to the maximum allowed. 
Curtis Ballard 
Hewlett Packard 
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Thursday, October 01, 2009 1:46 PM
To: t10 at t10.org
Subject: SSC-4: Programmable Early Warning question
Tapeheads, 
I wonder if we should protect the programmable early warning from being 
set to too large a value.  Should we add some statement like the following 
to SSC-4? 
If PEWS field of Device Configuration Extension mode page is set to a 
value larger than the tapes capacity, then the Mode Select should be 
rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 


From kdbutt at us.ibm.com  Fri Oct  2 10:12:02 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 2 Oct 2009 10:12:02 -0700
Subject: SSC-4: Programmable Early Warning question
Message-ID: <mailman.635.1441607350.22516.t10@sandbox.t10.org>

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

Dennis,
The RECOVERED ERROR/PARAMETERS ROUNDED response is specified in SPC-4 for 
use when parameters are rounded.  This should be what we do at a minimum. 
There is no restriction on a volume being loaded and I suspect that the 
users of the PEWS would not want there to be this restriction.	This 
drives an implementer to either chose:
a)  a maximum supported value that is less than the native capacity of the 
volumes supported (though Set Capacity could mess that up); or
b) on volume state changing from unmounted to mounted, checking PEWS field 
and, if necessary, modify the value to the now current maximum value and 
establish a UA for MODE PARAMETERS CHANGED.
I am not sure that either solution is ideal, but I think either solution 
would work - or a combination of both where the UA would only be required 
if the capacity of a supported volume had been modified by a Set Capacity 
command to a capacity less than the value chosen for the maximum PEWS 
value supported.  I suspect that users would really only desire a max 
capacity of somewhere less than about 10 GB.  However, I don't think we 
should limit ourselves to that in the standard.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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:
Dennis Painter <dennis at hale-pohaku.net>
To:
"t10 at t10.org" <t10 at t10.org>
Date:
10/02/2009 09:46 AM
Subject:
Re: SSC-4: Programmable Early Warning question
* From the T10 Reflector (t10 at t10.org), posted by:
* Dennis Painter <dennis at hale-pohaku.net>
*
Protection from it being set to a value greater that the media capacity 
is good. I favor recovered error as the software can accept it and 
continue or has the option to read the PEWS setting.
Is it allowed for the application client to set PEWS if there is no 
media present? I did not find a restriction in the current draft but it 
may not be where I looked.
If not restricted and media of different capacity is supported then 
there is a potential problem of PEWS being set for a larger capacity 
tape and having a smaller capacity tape inserted. If PEWS is cleared on 
media removal and cannot be set without media present then there would 
be no issue.
Dennis Painter
Ballard, Curtis C (StorageWorks) wrote:
> In the interest of having a complete specification it would be 
> appropriate to specify behavior although I would hope that an 
> application would never make that mistake.
> 
> Rather than reject the command I would be inclined to have a device 
> specific maximum PEWS zone and report a recovered error with the PEWS 
> zone set to the maximum allowed.
> 
> Curtis Ballard
> Hewlett Packard
>
> ------------------------------------------------------------------------
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of 
> *Kevin D Butt
> *Sent:* Thursday, October 01, 2009 1:46 PM
> *To:* t10 at t10.org
> *Subject:* SSC-4: Programmable Early Warning question
>
>
> Tapeheads,
>
> I wonder if we should protect the programmable early warning from 
> being set to too large a value.  Should we add some statement like the 
> following to SSC-4?
>
> If PEWS field of Device Configuration Extension mode page is set to a 
> value larger than the tapes capacity, then the Mode Select should be 
> rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> 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/ 
--------------050506040709020403060503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Protection from it being set to a value greater that the media capacity is 
good. I favor recovered error as the software can accept it and continue 
or has the option to read the PEWS setting.
Is it allowed for the application client to set PEWS if there is no media 
present? I did not find a restriction in the current draft but it may not 
be where I looked.
If not restricted and media of different capacity is supported then there 
is a potential problem of PEWS being set for a larger capacity tape and 
having a smaller capacity tape inserted. If PEWS is cleared on media 
removal and cannot be set without media present then there would be no 
issue.
Dennis Painter
Ballard, Curtis C (StorageWorks) wrote: 
>In the interest of having a complete specification it would be 
appropriate to specify behavior although I would hope that an application 
would never make that mistake.
> 
>Rather than reject the command I would be inclined to have a device 
specific maximum PEWS zone and report a recovered error with the PEWS zone 
set to the maximum allowed.
> 
>Curtis Ballard
>Hewlett Packard
>
>
>----------
>From: <mailto:owner-t10 at t10.org>owner-t10 at t10.org [
mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
>Sent: Thursday, October 01, 2009 1:46 PM
>To: <mailto:t10 at t10.org>t10 at t10.org
>Subject: SSC-4: Programmable Early Warning question
>
>
>Tapeheads, 
>
>I wonder if we should protect the programmable early warning from being 
set to too large a value.  Should we add some statement like the following 
to SSC-4? 
>
>If PEWS field of Device Configuration Extension mode page is set to a 
value larger than the tapes capacity, then the Mode Select should be 
rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST. 
>
>Thanks, 
>
>Kevin D. Butt
>SCSI & Fibre Channel Architect, Tape Firmware
>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/ 
--------------050506040709020403060503--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Fri Oct  2 11:21:06 2009
From: roweber at IEEE.org (Ralph Weber)
Date: Fri, 02 Oct 2009 13:21:06 -0500
Subject: Read Buffer mode 03h
Message-ID: <mailman.636.1441607350.22516.t10@sandbox.t10.org>

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

Robert,
The cited text was removed in SPC-4 r12 in response to
the following proposal:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=06-362r7.pdf
I suspect that the authors of that proposal felt that the
needed information was covered in the new 5.11.2 (Retrieving
error history with the READ BUFFER command) subclause which
has been promoted to 5.12.2 in SPC-4 r22:
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r22.pdf
All the best,
.Ralph
Payne_Robert at emc.com wrote:
> Section 6.15.5 of SPC-3 included the following:
>  
> "If there is no buffer associated with the specified buffer ID, the 
> device server shall return all zeros in the READ BUFFER descriptor."
>  
> I recently noticed that the current draft of SPC-4 does not include 
> this text. 
>  
> I am looking for background information on why this text is missing 
> from SPC-4.
>  
> Best Regards,
> Robert Payne
> Senior Software Engineer
> Global Platform Software
> EMC


From scotb at us.ibm.com  Fri Oct  2 11:43:27 2009
From: scotb at us.ibm.com (Scot Baumgartner)
Date: Fri, 2 Oct 2009 13:43:27 -0500
Subject: SAS-2.1 STATEYE Code.  Reference Transmitter/Receiver Device Termination
Message-ID: <mailman.637.1441607350.22516.t10@sandbox.t10.org>

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

There is something that I am confused about.	I expected the Reference 
Transmitter Device Termination (TxRefTerm.s4p) and the Reference Receiver 
Device Termination (RxRefTerm.s4p) to be used in the SAS-2.1 Annex C 
StatEye code.	  But it is not.   
Is the user expected to add these, or equivalent,  to their own version of 
the StatEye code? 
--- Some Notes.  From  sas21-r04.pdf  ----- 
- pg 130, Section 5.6.5 TxRx connection characteristics. 
  "Simulation results using: 
   b) the reference transmitter device 
   c) the reference receiver device 
- pg 158.  Section 5.8.4.6.5 Reference transmitter device characteristics 
  Reference TX Device is used for TxRx connection compliance testing. 
 TxRefTerm.s4p is part of Reference TX Device 
Scot Baumgartner.  IBM Austin, Texas.  512-286-5273.  363-5273


From lohmeyer at t10.org  Sat Oct  3 23:00:50 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 4 Oct 2009 00:00:50 -0600
Subject: Recent T10 documents uploaded since 2009/09/27
Message-ID: <mailman.638.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPC-4 Change power condition timer behavior when commands are received
(by: Gerald Houlder)
T10/09-250r2   Uploaded: 2009/09/29   287092 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-250r2.pdf
SPC-4 Change power condition timer behavior when commands are received
(by: Gerald Houlder)
T10/09-250r3   Uploaded: 2009/10/02   310858 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-250r3.pdf
SPL - STP extended buffer support
(by: Tim Symons)
T10/09-268r3   Uploaded: 2009/10/02   128262 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-268r3.pdf
SPC-4 - Adding a new VPD bit indicating download microcode behavior
(by: Mark Evans)
T10/09-294r1   Uploaded: 2009/09/29   25291 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-294r1.pdf
SSC-4 Identification of key associated data format
(by: Curtis Ballard)
T10/09-302r1   Uploaded: 2009/09/28   91259 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-302r1.pdf
SBC-3 Add log page for solid state drive (SSD)
(by: Gerald Houlder)
T10/09-322r1   Uploaded: 2009/10/02   172743 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-322r1.pdf
SSC-4: Append-only mode
(by: Kevin Butt)
T10/09-356r0   Uploaded: 2009/09/29   82113 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-356r0.pdf
SSC-4: Append-only mode
(by: Kevin Butt)
T10/09-356r1   Uploaded: 2009/09/30   88467 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-356r1.pdf
SSC-4: Append-only mode
(by: Kevin Butt)
T10/09-356r2   Uploaded: 2009/10/01   91452 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-356r2.pdf
SPC-4, SBC-3 Relationship between power conditions and background
tasks
(by: Mark Evans)
T10/09-357r0   Uploaded: 2009/09/29   24720 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-357r0.pdf
SPL - Zone Persistence Fix
(by: Gregory Tabor)
T10/09-358r0   Uploaded: 2009/10/02   50469 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-358r0.pdf
Working Drafts
--------------
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 22       Uploaded: 2009/09/28   4816457 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r22.pdf
(Report generated on 2009/10/04 at 00:00:50)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From dennis at hale-pohaku.net  Fri Oct  2 14:08:31 2009
From: dennis at hale-pohaku.net (Dennis Painter)
Date: Fri, 02 Oct 2009 11:08:31 -1000
Subject: SSC-4: Programmable Early Warning question
Message-ID: <mailman.639.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Dennis Painter <dennis at hale-pohaku.net>
*
Hi Kevin,
I think (b) is a the best way to cover this.It should  not disrupt any
application software.
It would think it will also cover use of the SET CAPACITY command.
Thanks,
Dennis
Kevin D Butt wrote:
>
> Dennis,
>
> The RECOVERED ERROR/PARAMETERS ROUNDED response is specified in SPC-4
> for use when parameters are rounded.	This should be what we do at a
> minimum.
> There is no restriction on a volume being loaded and I suspect that
> the users of the PEWS would not want there to be this restriction.
>  This drives an implementer to either chose:
> a)  a maximum supported value that is less than the native capacity of
> the volumes supported (though Set Capacity could mess that up); or
> b) on volume state changing from unmounted to mounted, checking PEWS
> field and, if necessary, modify the value to the now current maximum
> value and establish a UA for MODE PARAMETERS CHANGED.
>
> I am not sure that either solution is ideal, but I think either
> solution would work - or a combination of both where the UA would only
> be required if the capacity of a supported volume had been modified by
> a Set Capacity command to a capacity less than the value chosen for
> the maximum PEWS value supported.  I suspect that users would really
> only desire a max capacity of somewhere less than about 10 GB.
>  However, I don't think we should limit ourselves to that in the
> standard.
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> 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: 	Dennis Painter <dennis at hale-pohaku.net>
> To:	"t10 at t10.org" <t10 at t10.org>
> Date: 	10/02/2009 09:46 AM
> Subject:	Re: SSC-4: Programmable Early Warning question
>
>
> ------------------------------------------------------------------------
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Dennis Painter <dennis at hale-pohaku.net>
> *
> Protection from it being set to a value greater that the media capacity
> is good. I favor recovered error as the software can accept it and
> continue or has the option to read the PEWS setting.
>
> Is it allowed for the application client to set PEWS if there is no
> media present? I did not find a restriction in the current draft but it
> may not be where I looked.
>
> If not restricted and media of different capacity is supported then
> there is a potential problem of PEWS being set for a larger capacity
> tape and having a smaller capacity tape inserted. If PEWS is cleared on
> media removal and cannot be set without media present then there would
> be no issue.
>
> Dennis Painter
>
>
> Ballard, Curtis C (StorageWorks) wrote:
> > In the interest of having a complete specification it would be
> > appropriate to specify behavior although I would hope that an
> > application would never make that mistake.
> >
> > Rather than reject the command I would be inclined to have a device
> > specific maximum PEWS zone and report a recovered error with the PEWS
> > zone set to the maximum allowed.
> >
> > Curtis Ballard
> > Hewlett Packard
> >
> > ------------------------------------------------------------------------
> > *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of
> > *Kevin D Butt
> > *Sent:* Thursday, October 01, 2009 1:46 PM
> > *To:* t10 at t10.org
> > *Subject:* SSC-4: Programmable Early Warning question
> >
> >
> > Tapeheads,
> >
> > I wonder if we should protect the programmable early warning from
> > being set to too large a value.  Should we add some statement like the
> > following to SSC-4?
> >
> > If PEWS field of Device Configuration Extension mode page is set to a
> > value larger than the tapes capacity, then the Mode Select should be
> > rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
> >
> > Thanks,
> >
> > Kevin D. Butt
> > SCSI & Fibre Channel Architect, Tape Firmware
> > 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/
>
> --------------050506040709020403060503
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> Protection from it being set to a value greater that the media
> capacity is good. I favor recovered error as the software can accept
> it and continue or has the option to read the PEWS setting.
>
> Is it allowed for the application client to set PEWS if there is no
> media present? I did not find a restriction in the current draft but
> it may not be where I looked.
>
> If not restricted and media of different capacity is supported then
> there is a potential problem of PEWS being set for a larger capacity
> tape and having a smaller capacity tape inserted. If PEWS is cleared
> on media removal and cannot be set without media present then there
> would be no issue.
>
> Dennis Painter
>
>
> Ballard, Curtis C (StorageWorks) wrote:
> >In the interest of having a complete specification it would be
> appropriate to specify behavior although I would hope that an
> application would never make that mistake.
> >
> >Rather than reject the command I would be inclined to have a device
> specific maximum PEWS zone and report a recovered error with the PEWS
> zone set to the maximum allowed.
> >
> >Curtis Ballard
> >Hewlett Packard
> >
> >
> >----------
> >From: <mailto:owner-t10 at t10.org>owner-t10 at t10.org
> [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
> >Sent: Thursday, October 01, 2009 1:46 PM
> >To: <mailto:t10 at t10.org>t10 at t10.org
> >Subject: SSC-4: Programmable Early Warning question
> >
> >
> >Tapeheads,
> >
> >I wonder if we should protect the programmable early warning from
> being set to too large a value.  Should we add some statement like the
> following to SSC-4?
> >
> >If PEWS field of Device Configuration Extension mode page is set to a
> value larger than the tapes capacity, then the Mode Select should be
> rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
> >
> >Thanks,
> >
> >Kevin D. Butt
> >SCSI & Fibre Channel Architect, Tape Firmware
> >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/
>
> --------------050506040709020403060503--
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
--------------010906030203020303000607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Hi Kevin,
I think (b) is a the best way to cover this.It should  not disrupt any
application software. 
It would think it will also cover use of the SET CAPACITY command.
Thanks,
Dennis
Kevin D Butt wrote: 
>Dennis, 
>
>The RECOVERED ERROR/PARAMETERS ROUNDED response is specified in SPC-4 for
use when parameters are rounded.  This should be what we do at a minimum.   
>There is no restriction on a volume being loaded and I suspect that the
users of the PEWS would not want there to be this restriction.	This drives
an implementer to either chose: 
>a)  a maximum supported value that is less than the native capacity of the
volumes supported (though Set Capacity could mess that up); or 
>b) on volume state changing from unmounted to mounted, checking PEWS field
and, if necessary, modify the value to the now current maximum value and
establish a UA for MODE PARAMETERS CHANGED. 
>
>I am not sure that either solution is ideal, but I think either solution
would work - or a combination of both where the UA would only be required if
the capacity of a supported volume had been modified by a Set Capacity
command to a capacity less than the value chosen for the maximum PEWS value
supported.  I suspect that users would really only desire a max capacity of
somewhere less than about 10 GB.  However, I don't think we should limit
ourselves to that in the standard. 
>
>Thanks, 
>
>Kevin D. Butt
>SCSI & Fibre Channel Architect, Tape Firmware
>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: Dennis Painter <mailto:dennis at hale-pohaku.net><dennis at hale-pohaku.net> >To: <mailto:t10 at t10.org>"t10 at t10.org" <mailto:t10 at t10.org><t10 at t10.org> 
>Date: 10/02/2009 09:46 AM 
>Subject: Re: SSC-4: Programmable Early Warning question 
>
>
>
>
>
>* From the T10 Reflector (<mailto:t10 at t10.org>t10 at t10.org), posted by:
>* Dennis Painter <mailto:dennis at hale-pohaku.net><dennis at hale-pohaku.net>
>*
>Protection from it being set to a value greater that the media capacity 
>is good. I favor recovered error as the software can accept it and 
>continue or has the option to read the PEWS setting.
>
>Is it allowed for the application client to set PEWS if there is no 
>media present? I did not find a restriction in the current draft but it 
>may not be where I looked.
>
>If not restricted and media of different capacity is supported then 
>there is a potential problem of PEWS being set for a larger capacity 
>tape and having a smaller capacity tape inserted. If PEWS is cleared on 
>media removal and cannot be set without media present then there would 
>be no issue.
>
>Dennis Painter
>
>
>Ballard, Curtis C (StorageWorks) wrote:
>> In the interest of having a complete specification it would be 
>> appropriate to specify behavior although I would hope that an 
>> application would never make that mistake.
>>  
>> Rather than reject the command I would be inclined to have a device 
>> specific maximum PEWS zone and report a recovered error with the PEWS 
>> zone set to the maximum allowed.
>>  
>> Curtis Ballard
>> Hewlett Packard
>>
>> ------------------------------------------------------------------------
>> *From:* <mailto:owner-t10 at t10.org>owner-t10 at t10.org
[mailto:owner-t10 at t10.org] *On Behalf Of 
>> *Kevin D Butt
>> *Sent:* Thursday, October 01, 2009 1:46 PM
>> *To:* <mailto:t10 at t10.org>t10 at t10.org
>> *Subject:* SSC-4: Programmable Early Warning question
>>
>>
>> Tapeheads,
>>
>> I wonder if we should protect the programmable early warning from 
>> being set to too large a value.  Should we add some statement like the 
>> following to SSC-4?
>>
>> If PEWS field of Device Configuration Extension mode page is set to a 
>> value larger than the tapes capacity, then the Mode Select should be 
>> rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
>>
>> Thanks,
>>
>> Kevin D. Butt
>> SCSI & Fibre Channel Architect, Tape Firmware
>> 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/ 
>
>--------------050506040709020403060503
>Content-Type: text/html; charset=ISO-8859-1
>Content-Transfer-Encoding: 7bit
>
><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>Protection from it being set to a value greater that the media capacity is
good. I favor recovered error as the software can accept it and continue or
has the option to read the PEWS setting.
>
>Is it allowed for the application client to set PEWS if there is no media
present? I did not find a restriction in the current draft but it may not be
where I looked.
>
>If not restricted and media of different capacity is supported then there is
a potential problem of PEWS being set for a larger capacity tape and having a
smaller capacity tape inserted. If PEWS is cleared on media removal and
cannot be set without media present then there would be no issue.
>
>Dennis Painter
>
>
>Ballard, Curtis C (StorageWorks) wrote: 
>>In the interest of having a complete specification it would be appropriate
to specify behavior although I would hope that an application would never
make that mistake.
>> 
>>Rather than reject the command I would be inclined to have a device
specific maximum PEWS zone and report a recovered error with the PEWS zone
set to the maximum allowed.
>> 
>>Curtis Ballard
>>Hewlett Packard
>>
>>
>>----------
>>From:
<<mailto:owner-t10 at t10.org>mailto:owner-t10 at t10.org><mailto:owner-t10 at t10.org
>owner-t10 at t10.org [<mailto:owner-t10 at t10.org>mailto:owner-t10 at t10.org] On
Behalf Of Kevin D Butt
>>Sent: Thursday, October 01, 2009 1:46 PM
>>To: <<mailto:t10 at t10.org>mailto:t10 at t10.org><mailto:t10 at t10.org>t10 at t10.org
>>Subject: SSC-4: Programmable Early Warning question
>>
>>
>>Tapeheads, 
>>
>>I wonder if we should protect the programmable early warning from being set
to too large a value.  Should we add some statement like the following to
SSC-4? 
>>
>>If PEWS field of Device Configuration Extension mode page is set to a value
larger than the tapes capacity, then the Mode Select should be rejected with
ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST. 
>>
>>Thanks, 
>>
>>Kevin D. Butt
>>SCSI & Fibre Channel Architect, Tape Firmware
>>MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
>>Tel: 520-799-5280
>>Fax: 520-799-2723 (T/L:321)
>>Email address:
<mailto:kdbutt at us.ibm.com><mailto:kdbutt at us.ibm.com
>kdbutt at us.ibm.com
>><http://www-03.ibm.com/servers/stora">http://www-03.ibm.com/servers/storage/>http://www-03.ibm.com/servers/stora
ge/ 
>
>--------------050506040709020403060503--
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to
<mailto:majordomo at t10.org>majordomo at t10.org
>
--------------010906030203020303000607--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Daniel.Colegrove at hitachigst.com  Mon Oct  5 09:22:42 2009
From: Daniel.Colegrove at hitachigst.com (Daniel.Colegrove at hitachigst.com)
Date: Mon, 5 Oct 2009 09:22:42 -0700
Subject: T10 November Meeting Hotel Reservation Reminder (Please make your
 reservations)
Message-ID: <mailman.640.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Daniel.Colegrove at hitachigst.com
*
The cut off date for the November meeting is October 19th. So far the
room block is about 1/3 full. Please make your reservations.
Meeting Announcement:
http://www.t10.org/ftp/t10/announce/ann-m094.pdf
Link for Hotel Reservations:
https://resweb.passkey.com/go/hitachiglobalstoragetech
Or Phone: 1-800-HRD-ROCK
Our group name is Hitachi Global Storage Technologies. Please
mention it when calling.
If you have any difficulty please let me know.
Best Regards,
Daniel J. Colegrove
Hitachi Global Storage Technologies
daniel.colegrove at hitachigst.com
(702) 614-6119
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Barry.Olawsky at hp.com  Mon Oct  5 11:48:13 2009
From: Barry.Olawsky at hp.com (Olawsky, Barry)
Date: Mon, 5 Oct 2009 18:48:13 +0000
Subject: SFF-8449 / 8636 Conference Call Minutes, October 1, 2009
Message-ID: <mailman.641.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Olawsky, Barry" <Barry.Olawsky at hp.com>
*
Minutes of SFF-8449 / 8636 conference call October 1, 2009
Attendance:
Mr. Min-Jie Chong			Agilent Technologies
Mr. Jim McGrath 		Cinch
Mr. Mickey Felton			EMC
Mr. Jim David			FCI
Ms. Katharine Schmidtke 	Finisar Corp.			  
Mr. Elwood Parsons		Foxconn Electronics		    
Mr. Barry Olawsky			Hewlett Packard Co.
Mr. Gourgen Oganessyan		Intersel
Mr. Harvey Newman			LSI Corp 
Mr. Gabriel Romero		LSI Corp.     
Mr. Brian Day			LSI Corp		      
Mr. Brad Besmer 		LSI Corp.		      
Mr. Galen Fromm 		Molex Inc.			    
Mr. Michael Rost			Molex Inc.
Mr. Chris Fore			NetApp	      
Mr. Alvin Cox			Seagate Technology	
Mr. Scott Shuey 		TycoElectronics 		    
Mr. Toney Chew			Volex, Inc.			  
Mr. Larry McMillan		WDC
Mr. Matt Davis			Zarlink Semiconductor		  
20 in attendance
Agenda:
Discuss proposed content for SFF-8636 (Common Management Interface) and
SFF-8449 (Mini Multilane Series Management Interface). SFF-8436 (QSFP+ Copper
and Optical Transceiver) is to be used as a basis for SFF-8636.
Discussion:
Barry Olawsky (HP) shared a shared SFF-8636 definitions and interface
signals. See bottom for attachment.
The first discussion topic was how to apply the interconnect terminology
"fixed" and "free" to the management interface. Barry Olawsky (HP) shared a
file which included "fixed" and "free" definitions from SFF-8644, a proposed
definition of fixed and free for SFF-8636 and graphical representations of
all interconnect components identified as fixed and free. Several suggestions
were made during the meeting that Barry will incorporate into his next draft.
Specifically,
1) Clearly indicate that the 2-wire management interface does not go from one
end of the cable to the other
2) Indicate, on the proposed diagrams, what segments of the interconnect are
within the scope of SFF-8636 and which are not (for example, 8636 will not
address high speed differential signaling or optical interfaces)
3) Provide a more detailed diagram (possibly a block diagram) of the
management interface circuitry that resides not only in the cable side but
also the system side. This could include the 2-wire slave and master
4) Replace "end-to-end" references to "free-to-free" or "fixed-to-fixed"
Continuing on with the definition section, it was recommended that the terms
"passive" and "active" change to "only requiring power for the management
interface" and "requires power in addition to what the management interface
circuitry consumes".
The discussion went off on a tangent to address what how wide designs (those
large than 4X) would be implemented. Molex proposed cost reducing the designs
by using only one paddle card and one non-volatile storage device. However,
the general consensus was that such a method would create additional
complexity in the memory map and the proposal was withdrawn for now.
Barry presented a list of all necessary SFF-8636 interface signals. Initially
his objective was to include only those signals common to all interfaces
referencing SFF-8636. That list included only the 2-wire clock and data would
be required for the management interface. However, Mike Rost pointed out some
signals of the signals perceived as optional would still have to be defined
since their functionality is documented in the memory map (for example,
interrupt). Barry will modify his proposal to account for this.
The meeting adjourned at ~11:10AM CDT
Call schedule:
Next conference call: October 8, 2009
Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2.1 PHY WG 
Date: Thursday, October 8, 2009 
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) 
Meeting Number: 826 515 680 
Meeting Password: newsas 
(Note: When logging onto WEBEX, please include your company following your
name. This will help the person recording attendance.)
----------    DISCUSSION MATERIAL    -----------
|FROM SFF-8644:
Fixed: Used to describe the gender of the mating side of the connector that
accepts its mate upon mating. This gender is frequently, but not always,
associated with the common terminology "receptacle". Other terms commonly
used are "female" and "socket connector". The term "fixed" is adopted from
EIA standard terminology as the gender that most commonly exists on the fixed
end of a connection, for example, on the board or bulkhead side. In this
specification "fixed" is specifically used to describe the mating side gender
illustrated in Figure 2.
Free: Used to describe the gender of the mating side of the connector that
penetrates its mate upon mating. This gender is frequently, but not always,
associated with the common terminology "plug". Other terms commonly used are
"male" and "pin connector". The term "free" is adopted from EIA standard
terminology as the gender that most commonly exists on the free end of a
connection, for example, on the cable side. In this specification "free" is
specifically used to describe the mating side gender illustrated in Figure 2.
PROPOSED SFF-8636 DEFINITIONS:
Fixed versus Free:
In this application the fixed side is one end of a point to point link
connected by one or more free side segments. Figure 1 illustrates how a
single free side segment connects two fixed side end points.
Figure 1
Figure 2 illustrates how multiple free side segments connect two fixed side
end points.
Figure 2
Passive:
A passive cable contains requires no power for an end to end connection to
operate properly. However, non-powered circuitry may be in the end to end
path.
Active:
An active cable requires power for the end-to-end path to operate properly.
*
* 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 Oct  6 09:12:24 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 06 Oct 2009 10:12:24 -0600
Subject: SAS Webinar: Advanced Connectivity Options
Message-ID: <mailman.642.1441607350.22516.t10@sandbox.t10.org>

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

From: Alice Tate <alice at scsita.org>
Date: Mon, 5 Oct 2009 12:44:13 -0600
Subject: SAS Webinar: Advanced Connectivity Options
STA is hosting a webinar on Thursday, November 5 at 9 AM pacific.
Below are the details. To register, go to:
<http://www.scsita.org/news_ev">http://www.scsita.org/news_events/webcast.html>http://www.scsita.org/news_ev
ents/webcast.html
Title: SAS Advanced Connectivity
Sponsored by STA Members: Intel, JDSU, & Seagate
Date: Thursday, Nov. 5
Time: 9 AM pacific.
Description:
SAS connectivity includes a varied set of components and interconnectivity
options used to accomplish diverse storage system objectives.
Attendees will learn:
?The details necessary to assemble and deliver compelling SAS solutions
?About the SAS Advanced Connectivity Roadmap
?What SAS Connectivity Management means 
?Why SAS Advanced Connectivity is important for extending SAS? reach into
emerging cloud computing, large data centers and enterprise storage
opportunities.
Presented by: Harry Mason, President, STA and Director, Industry Marketing,
LSI
Supported by:
STA VP Marty Czekalski (Interface Architecture Initiative Manager, Seagate)
STA Board Member & Secretary Cameron Brett (Product Marketing Manager,
PMC-Sierra)
STA Board Member Paul Vogt (Senior Director Product Management, Xyratex)
Please feel free to publicize this webinar to your sales team, channel,
customers, partners & more.
Go to:
<http://www.scsita.org">http://www.scsita.org/news_events/webcast_banners.html>http://www.scsita.org
/news_events/webcast_banners.html to download banners promoting the webinar.
Let me know if you have any questions!
Best,
Alice


From roweber at IEEE.org  Tue Oct  6 10:43:01 2009
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 06 Oct 2009 12:43:01 -0500
Subject: Conflicted List Format Log Parameter Rules
Message-ID: <mailman.643.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I have encountered something that looks like total nonsense
in the SPC-4 table which defines how the Parameter Control
Byte is used for List Format Log Parameters.
Some slash-and-burn fixes are proposed in:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-359r0.pdf
Log Parameter experts are advised to read this proposal and
sharpen their knives for Las Vegas.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Tue Oct  6 14:39:43 2009
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 06 Oct 2009 16:39:43 -0500
Subject: Log page consistency
Message-ID: <mailman.644.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
One of the recently espoused goals it to "describe all
log pages consistently".
This goal might be taken to mean that each and every
log page should be described in a separate subclause.
If this interpretation of the goal is applied to SPC-4,
then the subclause numbered 7.2.5 in r22 will become
four subclauses each with approximately the same content.
Does anybody care to express an opinion on the goal
and/or its interpretation?
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Tue Oct  6 14:56:25 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 6 Oct 2009 14:56:25 -0700
Subject: SSC-4: Programmable Early Warning question
Message-ID: <mailman.645.1441607350.22516.t10@sandbox.t10.org>

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

Dennis and all,
Another item to add to the "what do we do when..." list related to 
programmable early warning is what happens when a tape is partitioned such 
that one of the partitions becomes smaller than PEWZ.  Not that like early 
warning, PEWZ is a device behavior and is not related to a specific 
partition.
What do we specify and what do we leave as vendor implementation?
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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:
Dennis Painter <dennis at hale-pohaku.net>
To:
Kevin D Butt/Tucson/IBM at IBMUS
Cc:
"t10 at t10.org" <t10 at t10.org>
Date:
10/05/2009 08:48 AM
Subject:
Re: SSC-4: Programmable Early Warning question
Sent by:
owner-t10 at t10.org
* From the T10 Reflector (t10 at t10.org), posted by:
* Dennis Painter <dennis at hale-pohaku.net>
*
Hi Kevin,
I think (b) is a the best way to cover this.It should  not disrupt any
application software.
It would think it will also cover use of the SET CAPACITY command.
Thanks,
Dennis
Kevin D Butt wrote:
>
> Dennis,
>
> The RECOVERED ERROR/PARAMETERS ROUNDED response is specified in SPC-4
> for use when parameters are rounded.	This should be what we do at a
> minimum.
> There is no restriction on a volume being loaded and I suspect that
> the users of the PEWS would not want there to be this restriction.
>  This drives an implementer to either chose:
> a)  a maximum supported value that is less than the native capacity of
> the volumes supported (though Set Capacity could mess that up); or
> b) on volume state changing from unmounted to mounted, checking PEWS
> field and, if necessary, modify the value to the now current maximum
> value and establish a UA for MODE PARAMETERS CHANGED.
>
> I am not sure that either solution is ideal, but I think either
> solution would work - or a combination of both where the UA would only
> be required if the capacity of a supported volume had been modified by
> a Set Capacity command to a capacity less than the value chosen for
> the maximum PEWS value supported.  I suspect that users would really
> only desire a max capacity of somewhere less than about 10 GB.
>  However, I don't think we should limit ourselves to that in the
> standard.
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> 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: 	Dennis Painter <dennis at hale-pohaku.net>
> To:	"t10 at t10.org" <t10 at t10.org>
> Date: 	10/02/2009 09:46 AM
> Subject:	Re: SSC-4: Programmable Early Warning question
>
>
> ------------------------------------------------------------------------
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Dennis Painter <dennis at hale-pohaku.net>
> *
> Protection from it being set to a value greater that the media capacity
> is good. I favor recovered error as the software can accept it and
> continue or has the option to read the PEWS setting.
>
> Is it allowed for the application client to set PEWS if there is no
> media present? I did not find a restriction in the current draft but it
> may not be where I looked.
>
> If not restricted and media of different capacity is supported then
> there is a potential problem of PEWS being set for a larger capacity
> tape and having a smaller capacity tape inserted. If PEWS is cleared on
> media removal and cannot be set without media present then there would
> be no issue.
>
> Dennis Painter
>
>
> Ballard, Curtis C (StorageWorks) wrote:
> > In the interest of having a complete specification it would be
> > appropriate to specify behavior although I would hope that an
> > application would never make that mistake.
> >
> > Rather than reject the command I would be inclined to have a device
> > specific maximum PEWS zone and report a recovered error with the PEWS
> > zone set to the maximum allowed.
> >
> > Curtis Ballard
> > Hewlett Packard
> >
> > 
------------------------------------------------------------------------
> > *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of
> > *Kevin D Butt
> > *Sent:* Thursday, October 01, 2009 1:46 PM
> > *To:* t10 at t10.org
> > *Subject:* SSC-4: Programmable Early Warning question
> >
> >
> > Tapeheads,
> >
> > I wonder if we should protect the programmable early warning from
> > being set to too large a value.  Should we add some statement like the
> > following to SSC-4?
> >
> > If PEWS field of Device Configuration Extension mode page is set to a
> > value larger than the tapes capacity, then the Mode Select should be
> > rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
> >
> > Thanks,
> >
> > Kevin D. Butt
> > SCSI & Fibre Channel Architect, Tape Firmware
> > 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/
>
> --------------050506040709020403060503
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> Protection from it being set to a value greater that the media
> capacity is good. I favor recovered error as the software can accept
> it and continue or has the option to read the PEWS setting.
>
> Is it allowed for the application client to set PEWS if there is no
> media present? I did not find a restriction in the current draft but
> it may not be where I looked.
>
> If not restricted and media of different capacity is supported then
> there is a potential problem of PEWS being set for a larger capacity
> tape and having a smaller capacity tape inserted. If PEWS is cleared
> on media removal and cannot be set without media present then there
> would be no issue.
>
> Dennis Painter
>
>
> Ballard, Curtis C (StorageWorks) wrote:
> >In the interest of having a complete specification it would be
> appropriate to specify behavior although I would hope that an
> application would never make that mistake.
> >
> >Rather than reject the command I would be inclined to have a device
> specific maximum PEWS zone and report a recovered error with the PEWS
> zone set to the maximum allowed.
> >
> >Curtis Ballard
> >Hewlett Packard
> >
> >
> >----------
> >From: <mailto:owner-t10 at t10.org>owner-t10 at t10.org
> [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
> >Sent: Thursday, October 01, 2009 1:46 PM
> >To: <mailto:t10 at t10.org>t10 at t10.org
> >Subject: SSC-4: Programmable Early Warning question
> >
> >
> >Tapeheads,
> >
> >I wonder if we should protect the programmable early warning from
> being set to too large a value.  Should we add some statement like the
> following to SSC-4?
> >
> >If PEWS field of Device Configuration Extension mode page is set to a
> value larger than the tapes capacity, then the Mode Select should be
> rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
> >
> >Thanks,
> >
> >Kevin D. Butt
> >SCSI & Fibre Channel Architect, Tape Firmware
> >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/
>
> --------------050506040709020403060503--
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
--------------010906030203020303000607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Hi Kevin,
I think (b) is a the best way to cover this.It should  not disrupt any 
application software. 
It would think it will also cover use of the SET CAPACITY command.
Thanks,
Dennis
Kevin D Butt wrote: 
>Dennis, 
>
>The RECOVERED ERROR/PARAMETERS ROUNDED response is specified in SPC-4 for 
use when parameters are rounded.  This should be what we do at a minimum.  
>There is no restriction on a volume being loaded and I suspect that the 
users of the PEWS would not want there to be this restriction.	This 
drives an implementer to either chose: 
>a)  a maximum supported value that is less than the native capacity of 
the volumes supported (though Set Capacity could mess that up); or 
>b) on volume state changing from unmounted to mounted, checking PEWS 
field and, if necessary, modify the value to the now current maximum value 
and establish a UA for MODE PARAMETERS CHANGED. 
>
>I am not sure that either solution is ideal, but I think either solution 
would work - or a combination of both where the UA would only be required 
if the capacity of a supported volume had been modified by a Set Capacity 
command to a capacity less than the value chosen for the maximum PEWS 
value supported.  I suspect that users would really only desire a max 
capacity of somewhere less than about 10 GB.  However, I don't think we 
should limit ourselves to that in the standard. 
>
>Thanks, 
>
>Kevin D. Butt
>SCSI & Fibre Channel Architect, Tape Firmware
>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: Dennis Painter <mailto:dennis at hale-pohaku.net
><dennis at hale-pohaku.net> 
>To: <mailto:t10 at t10.org>"t10 at t10.org" <mailto:t10 at t10.org><t10 at t10.org> 
>Date: 10/02/2009 09:46 AM 
>Subject: Re: SSC-4: Programmable Early Warning question 
>
>
>
>
>
>* From the T10 Reflector (<mailto:t10 at t10.org>t10 at t10.org), posted by:
>* Dennis Painter <mailto:dennis at hale-pohaku.net><dennis at hale-pohaku.net>
>*
>Protection from it being set to a value greater that the media capacity 
>is good. I favor recovered error as the software can accept it and 
>continue or has the option to read the PEWS setting.
>
>Is it allowed for the application client to set PEWS if there is no 
>media present? I did not find a restriction in the current draft but it 
>may not be where I looked.
>
>If not restricted and media of different capacity is supported then 
>there is a potential problem of PEWS being set for a larger capacity 
>tape and having a smaller capacity tape inserted. If PEWS is cleared on 
>media removal and cannot be set without media present then there would 
>be no issue.
>
>Dennis Painter
>
>
>Ballard, Curtis C (StorageWorks) wrote:
>> In the interest of having a complete specification it would be 
>> appropriate to specify behavior although I would hope that an 
>> application would never make that mistake.
>> 
>> Rather than reject the command I would be inclined to have a device 
>> specific maximum PEWS zone and report a recovered error with the PEWS 
>> zone set to the maximum allowed.
>> 
>> Curtis Ballard
>> Hewlett Packard
>>
>> 
------------------------------------------------------------------------
>> *From:* <mailto:owner-t10 at t10.org>owner-t10 at t10.org [
mailto:owner-t10 at t10.org] *On Behalf Of 
>> *Kevin D Butt
>> *Sent:* Thursday, October 01, 2009 1:46 PM
>> *To:* <mailto:t10 at t10.org>t10 at t10.org
>> *Subject:* SSC-4: Programmable Early Warning question
>>
>>
>> Tapeheads,
>>
>> I wonder if we should protect the programmable early warning from 
>> being set to too large a value.  Should we add some statement like the 
>> following to SSC-4?
>>
>> If PEWS field of Device Configuration Extension mode page is set to a 
>> value larger than the tapes capacity, then the Mode Select should be 
>> rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST.
>>
>> Thanks,
>>
>> Kevin D. Butt
>> SCSI & Fibre Channel Architect, Tape Firmware
>> 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/ 
>
>--------------050506040709020403060503
>Content-Type: text/html; charset=ISO-8859-1
>Content-Transfer-Encoding: 7bit
>
><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>Protection from it being set to a value greater that the media capacity 
is good. I favor recovered error as the software can accept it and 
continue or has the option to read the PEWS setting.
>
>Is it allowed for the application client to set PEWS if there is no media 
present? I did not find a restriction in the current draft but it may not 
be where I looked.
>
>If not restricted and media of different capacity is supported then there 
is a potential problem of PEWS being set for a larger capacity tape and 
having a smaller capacity tape inserted. If PEWS is cleared on media 
removal and cannot be set without media present then there would be no 
issue.
>
>Dennis Painter
>
>
>Ballard, Curtis C (StorageWorks) wrote: 
>>In the interest of having a complete specification it would be 
appropriate to specify behavior although I would hope that an application 
would never make that mistake.
>> 
>>Rather than reject the command I would be inclined to have a device 
specific maximum PEWS zone and report a recovered error with the PEWS zone 
set to the maximum allowed.
>> 
>>Curtis Ballard
>>Hewlett Packard
>>
>>
>>----------
>>From: <<mailto:owner-t10 at t10.org>mailto:owner-t10 at t10.org><
mailto:owner-t10 at t10.org>owner-t10 at t10.org [<mailto:owner-t10 at t10.org>
mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
>>Sent: Thursday, October 01, 2009 1:46 PM
>>To: <<mailto:t10 at t10.org>mailto:t10 at t10.org><mailto:t10 at t10.org
>t10 at t10.org
>>Subject: SSC-4: Programmable Early Warning question
>>
>>
>>Tapeheads, 
>>
>>I wonder if we should protect the programmable early warning from being 
set to too large a value.  Should we add some statement like the following 
to SSC-4? 
>>
>>If PEWS field of Device Configuration Extension mode page is set to a 
value larger than the tapes capacity, then the Mode Select should be 
rejected with ILLEGAL REQUEST, INVALID FIELD IN PARAMETER LIST. 
>>
>>Thanks, 
>>
>>Kevin D. Butt
>>SCSI & Fibre Channel Architect, Tape Firmware
>>MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
>>Tel: 520-799-5280
>>Fax: 520-799-2723 (T/L:321)
>>Email address: <mailto:kdbutt at us.ibm.com><
mailto:kdbutt at us.ibm.com>kdbutt at us.ibm.com
>><http://www-03.ibm.com/servers/storage/&gt;
http://www-03.ibm.com/servers/storage/ 
>
>--------------050506040709020403060503--
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to <mailto:majordomo at t10.org
>majordomo at t10.org
>
--------------010906030203020303000607--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Tue Oct  6 15:03:47 2009
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 06 Oct 2009 17:03:47 -0500
Subject: Additional Log Page Consistency Information
Message-ID: <mailman.646.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
To further lubricate the discussion of writing consistent
descriptions of all SPC-4-defined log pages, I have uploaded
the little bit of proposal that has been drafted to date.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-360r0.pdf
If nothing else, the uploaded document will provide hints
of the degree of butchery I am willing to commit in the
name of consistency.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Tue Oct  6 15:55:58 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 6 Oct 2009 15:55:58 -0700
Subject: Log page consistency
Message-ID: <mailman.647.1441607350.22516.t10@sandbox.t10.org>

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

Ralph,
I would prefer to interpret the goal of "describe all log pages 
consistently" to mean that the descriptions are in the same format and 
uses the same terminology's, etc.  For 7.2.5 I would say the description 
of each parameter should be consistent with how parameters are described. 
However, I would be happy to still have it apply to the four separate page 
codes all in the same subclause.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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 <roweber at IEEE.org>
To:
"'t10 at t10.org'" <t10 at t10.org>
Date:
10/06/2009 03:24 PM
Subject:
Log page consistency
Sent by:
owner-t10 at t10.org
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
One of the recently espoused goals it to "describe all
log pages consistently".
This goal might be taken to mean that each and every
log page should be described in a separate subclause.
If this interpretation of the goal is applied to SPC-4,
then the subclause numbered 7.2.5 in r22 will become
four subclauses each with approximately the same content.
Does anybody care to express an opinion on the goal
and/or its interpretation?
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From tjmac at tolisgroup.com  Tue Oct  6 16:56:55 2009
From: tjmac at tolisgroup.com (Tim Jones)
Date: Tue, 6 Oct 2009 16:56:55 -0700
Subject: Log page consistency
Message-ID: <mailman.648.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Tim Jones <tjmac at tolisgroup.com>
*
Ralph,
As a software developer, I can see that this would be very helpful.   
Since the specs are usually accessed as PDF's, bytes are cheap, so  
nearly duplicated entries will definitely be worth their cost if the  
result is a more robust representation for my engineering team.
Tim
On Oct 6, 2009, at 2:39 PM, Ralph Weber wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> One of the recently espoused goals it to "describe all
> log pages consistently".
>
> This goal might be taken to mean that each and every
> log page should be described in a separate subclause.
>
> If this interpretation of the goal is applied to SPC-4,
> then the subclause numbered 7.2.5 in r22 will become
> four subclauses each with approximately the same content.
>
> Does anybody care to express an opinion on the goal
> and/or its interpretation?
>
> All the best,
>
> .Ralph
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gericson at townisp.com  Tue Oct  6 19:27:58 2009
From: gericson at townisp.com (gericson at townisp.com)
Date: Wed, 7 Oct 2009 02:27:58 +0000
Subject: Log page consistency
Message-ID: <mailman.649.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* gericson at townisp.com
*
Would it be more readable to describe the common characteristics of these log
pages once and then use four additional clauses to describe the unique
aspects of each log page.
George
------Original Message------
From: Ralph Weber
Sender: owner-t10 at t10.org
To: 't10 at t10.org'
Subject: Log page consistency
Sent: Oct 6, 2009 17:39
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
One of the recently espoused goals it to "describe all
log pages consistently".
This goal might be taken to mean that each and every
log page should be described in a separate subclause.
If this interpretation of the goal is applied to SPC-4,
then the subclause numbered 7.2.5 in r22 will become
four subclauses each with approximately the same content.
Does anybody care to express an opinion on the goal
and/or its interpretation?
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
Sent via BlackBerry by AT&T
*
* 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  Wed Oct  7 07:25:54 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Wed, 7 Oct 2009 09:25:54 -0500
Subject: Log page consistency
Message-ID: <mailman.650.1441607350.22516.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910070_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910070_graycol.gif">graycol.gif</a>
Attachment #2: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910070_pic26177.gif">pic26177.gif</a>
Attachment #3: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910070_ecblank.gif">ecblank.gif</a>

My suggestion for achieving this goal would be:
(a) have an overview clause that introduces the four log pages and includes
a generic "log page header with a number of parameters" table and a generic
"parameter descriptor with header and parameter bytes" table.
(b) Have 4 sub-clauses, one for each log page, that consist of a parameter
table (i.e., a table showing each parameter number and parameter
description in a row of the table) and a unique description of each
parameter. The parameter descriptions (or maybe boilerplate at the start of
each sub-clause) should include a list of commands for which the counters
apply; we may need to decide whether to include such new commands like
ORWRITE and nuclear Test and Set in these lists. We may have to
re-establish whether each counter applies to bytes transferred over the
interface or to bytes transferred to/ from the medium (I think we intended
"transferred over the interface" but that isn't clear in the existing
descriptions).
(c) We may want to sprinkle in some implementation guidance. For example,
recommend that parameter lengths be a multiple of four and perhaps
recommend a minimum parameter length for each parameter. This is new
material needs discussion at a CAP meeting.
	     Ralph Weber					       
	     <roweber at IEEE.org					       
	     >								To
	     Sent by:		       "'t10 at t10.org'" <t10 at t10.org>   
	     owner-t10 at t10.org						cc
	     No Phone Info					       
	     Available						   Subject
				       Log page consistency	       
	     10/06/2009 04:39					       
	     PM 						       
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
One of the recently espoused goals it to "describe all
log pages consistently".
This goal might be taken to mean that each and every
log page should be described in a separate subclause.
If this interpretation of the goal is applied to SPC-4,
then the subclause numbered 7.2.5 in r22 will become
four subclauses each with approximately the same content.
Does anybody care to express an opinion on the goal
and/or its interpretation?
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Wed Oct  7 08:33:15 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Wed, 7 Oct 2009 10:33:15 -0500
Subject: Comment on proposal 09-357r0
Message-ID: <mailman.651.1441607350.22516.t10@sandbox.t10.org>

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

Mark Evans recently posted proposal 09-357r0 (Relationship between low
power conditions and background tasks) and has asked for discussion of it
on the reflector. I'd like to offer my obervations.
I think the first four scenarios described in his proposal are sufficiently
described within the standards to arrive at these descriptions. The
descriptions are somewhat disk drive centric (e.g., giving special
consideration for START STOP UNIT and FORMAT comands) but I suspect these
same cases can be similary resolved for tape or other device classes with
similar device centric commands.
Scenario 5 proposes to add some mode bits to allow an initiator to choose
whether to let background tasks have priority over low power requests or
vice versa. I am not in favor of this concept.
Speaking for disk drives (other device classes may have a different
opinion), when we design background tasks they are for one reason -- to
increase the reliability of the disk drive. Let's be honest, background
tasks are a pain in the butt. They interfere with performance and power
savings, both of which are important to the customers. However the
customers also say that reliability is even more important than performance
or power savings.
My company will always want background tasks that ensure reliability to
take priority over low power conditions. All of my company's background
tasks fall into that category. Perhaps we can allow an initiator preference
to override background tasks that DO NOT enhance reliability. Then we end
up with a vendor specific interpretation of which background task might be
overridden and which ones are not, but I expect everyone will have
background tasks that are reliability related.
I think we are better off presuming background tasks are higher priority


From kdbutt at us.ibm.com  Wed Oct  7 08:39:21 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 7 Oct 2009 08:39:21 -0700
Subject: Log page consistency
Message-ID: <mailman.652.1441607350.22516.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_nameless-4068-5.gif">nameless-4068-5.gif</a>
Attachment #2: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_nameless-4068-6.gif">nameless-4068-6.gif</a>
Attachment #3: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_nameless-4068-7.gif">nameless-4068-7.gif</a>
Attachment #4: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_nameless-4068-8.gif">nameless-4068-8.gif</a>
Attachment #5: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_nameless-4068-9.gif">nameless-4068-9.gif</a>
Attachment #6: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_nameless-4068-10.gif">nameless-4068-10.gif</a>
Attachment #7: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_nameless-4068-11.gif">nameless-4068-11.gif</a>
Attachment #8: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_nameless-4068-12.gif">nameless-4068-12.gif</a>
Attachment #9: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910072_nameless-4068-13.gif">nameless-4068-13.gif</a>

I am not comfortable adding a list of which commands to which the counters 
apply.	For one, probably the least important reason, a list of commands 
if desired would belong in the command set standards.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:
Gerry.Houlder at seagate.com
To:
t10 at t10.org
Date:
10/07/2009 08:08 AM
Subject:
Re: Log page consistency
Sent by:
owner-t10 at t10.org
My suggestion for achieving this goal would be:
(a) have an overview clause that introduces the four log pages and 
includes a generic "log page header with a number of parameters" table and 
a generic "parameter descriptor with header and parameter bytes" table.
(b) Have 4 sub-clauses, one for each log page, that consist of a parameter 
table (i.e., a table showing each parameter number and parameter 
description in a row of the table) and a unique description of each 
parameter. The parameter descriptions (or maybe boilerplate at the start 
of each sub-clause) should include a list of commands for which the 
counters apply; we may need to decide whether to include such new commands 
like ORWRITE and nuclear Test and Set in these lists. We may have to 
re-establish whether each counter applies to bytes transferred over the 
interface or to bytes transferred to/ from the medium (I think we intended 
"transferred over the interface" but that isn't clear in the existing 
descriptions).
(c) We may want to sprinkle in some implementation guidance. For example, 
recommend that parameter lengths be a multiple of four and perhaps 
recommend a minimum parameter length for each parameter. This is new 
material needs discussion at a CAP meeting.
Ralph Weber <roweber at IEEE.org>
Ralph Weber <roweber at IEEE.org> 
Sent by: owner-t10 at t10.org
No Phone Info Available 
10/06/2009 04:39 PM
To
"'t10 at t10.org'" <t10 at t10.org>
cc
Subject
Log page consistency
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
One of the recently espoused goals it to "describe all
log pages consistently".
This goal might be taken to mean that each and every
log page should be described in a separate subclause.
If this interpretation of the goal is applied to SPC-4,
then the subclause numbered 7.2.5 in r22 will become
four subclauses each with approximately the same content.
Does anybody care to express an opinion on the goal
and/or its interpretation?
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
[attachment "pic26177.gif" deleted by Kevin D Butt/Tucson/IBM] 


From lohmeyer at t10.org  Wed Oct  7 09:24:08 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 07 Oct 2009 10:24:08 -0600
Subject: Fwd: [Chairs] IMPORTANT:  INCITS 2010 Invoicing Schedule and
  Information
Message-ID: <mailman.653.1441607350.22516.t10@sandbox.t10.org>

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

Please see the 2010 invoicing information below. -- John
>From: "Barra, Lynn" <lbarra at itic.org>
>To: "chairs at standards.incits.org" <chairs at standards.incits.org>
>CC: "Deutsch, Donald" <donald.deutsch at oracle.com>, "Hughes, Jim"
>	 <jim.hughes at microsoft.com>, "Wennblom, Philip"
<philip.c.wennblom at intel.com>,
>	 "Wright, Don" <don at lexmark.com>
>Date: Tue, 6 Oct 2009 19:07:31 -0600
>Subject: [Chairs] IMPORTANT:  INCITS 2010 Invoicing Schedule and Information
>
>To INCITS TC and TG Chairs ?
> 
>It?s that time of year again and the INCITS Secretariat has started the
process for generating invoices for 2010 participation. Note that the
membership cycle begins on December 1, 2009 and ends November 30, 2010.
> 
>In August, TC and TG Chairs were emailed a membership report of
organizations and representatives on record for their committee.   The
Secretariat has received some updated information from you and/or directly
|from members. When invoices are issued, the principal contact that INCITS has
on record is the individual who will receive the invoices (unless an
organization has requested a separate designed billing point of contact).
> 
>Beginning with the 2010 membership cycle, the automated features of the
billing system will be used to issue invoices, reminder notices, final
notices and sadly termination notices.	The schedule is as follows:
> 
>1.    October 29:  The billing system will take a snapshot of each committee
to generate invoices with existing information.
>
>2.    November 1: The 2010 invoices are emailed to the Principal
representative (or to the designed billing contact).
> 
>3.    December 1:  A 30-day reminder notice to unpaid organizations is
emailed to the Principal representative (or to the designed billing contact).
>
>4.    January 1:  Final notices to unpaid organizations are emailed to the
Principal representative (or to the designed billing contact). A summary of
organizations that received a final notice will be emailed to TC/TG Chairs on
January 4.
>
>5.    February 1:  Memberships are deactivated if unpaid and cancellation
notices are emailed to the Principal representative (or to the designed
billing contact).  If deactivated, organizations are welcome to re-establish
participation in accordance with the INCITS/RD-2 and should contact the
INCITS Secretariat. A summary of deactivated organizations will be emailed to
TC/TG Chairs on February 2.
>
>Principal representatives should be reminded that if they do not receive an
invoice, they should contact the Secretariat immediately. Maintaining
membership is the responsibility of the member organization (Principal and
Alternates).  Purchase orders, contracts and agreements must be fully
executed and received at the INCITS Secretariat before the February 1, 2010
deadline to ensure uninterrupted service.  For purchase orders, contracts and
agreements received after January 1, 2010, payment in full must be received
within 60 days to avoid deactivation.
>Note to Chairs:  
>Please ensure both Principal and Alternate members are aware of the above
schedule of invoicing activities.  Membership data can be provided upon
request and changes can be submitted via email. 
> 
>-	Committees already transitioned to ICMS - Chairs can log into ICMS
and download their rosters for review and members can view and update their
own participation or submit changes via email.
>-	Committees not transitioned to ICMS - Chairs should contact the
Secretariat for ICMS access to their rosters; membership changes can be
submitted via email.
> 
>Please contact the Secretariat any questions.
> 
> 
>Lynn Barra (lbarra at itic.org, 202-626-5739)
>Barbara Bennett (bbennett at itic.org, 202-626-5743)
>Serena Patrick (spatrick at itic.org, 202-626-5741) 
>Debbie Spittle (dspittle at itic.org, 202-626-5746)
> 
> 
> 


From kdbutt at us.ibm.com  Wed Oct  7 09:48:22 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 7 Oct 2009 09:48:22 -0700
Subject: SSC-4: Programmable Early Warning PEWS rounding (09-361)
Message-ID: <mailman.654.1441607350.22516.t10@sandbox.t10.org>

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

I have posted a proposal for the reflector traffic related to how to put 
limits on PEWS
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-361r0.pdf
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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 Mark.Evans at wdc.com  Wed Oct  7 09:45:35 2009
From: Mark.Evans at wdc.com (Mark Evans)
Date: Wed, 7 Oct 2009 09:45:35 -0700
Subject: Comment on proposal 09-357r0
Message-ID: <mailman.655.1441607350.22516.t10@sandbox.t10.org>

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

Hi Gerry,
I'm working on clarifying the scenarios described in 09-357r0.	I've deleted
the scenario with the requirement for a two-bit field in concert with what
you wrote, as I agree that having different behaviors is too complicated,
and, at least for HDDs, we want to be able to process background tasks
unless this type of action has been specifically prohibited by a command
|from an application client.  The following are my premises for this:
a)	  If a logical unit is in a low power state as the result of a
command (e.g., a START STOP UNIT command with the power condition field and
power condition modifier field set to cause the logical unit to transition
to the idle_a power condition), then the logical unit does not change state
to process background functions when timers or device-specific events occur;
and,
b)	 If a logical unit is in a low power state as the result of a power
condition timer expiring, then the logical unit changes state as necessary
to process background functions when timers or device-specific events occur.
Stay tuned.  I hope to have a new revision out this week with the goal being
that we discuss the new revision at CAP in November so I can get more input
before I make any specific proposed wording changes to draft standards.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
Office: 408.363.5257
Fax: 408.363.5139
Cell: 408.391.7805
Home: 408-746-3085
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Wednesday, October 07, 2009 8:33 AM
To: t10 at t10.org
Subject: Comment on proposal 09-357r0
Mark Evans recently posted proposal 09-357r0 (Relationship between low power
conditions and background tasks) and has asked for discussion of it on the
reflector. I'd like to offer my obervations.
I think the first four scenarios described in his proposal are sufficiently
described within the standards to arrive at these descriptions. The
descriptions are somewhat disk drive centric (e.g., giving special
consideration for START STOP UNIT and FORMAT comands) but I suspect these
same cases can be similary resolved for tape or other device classes with
similar device centric commands.
Scenario 5 proposes to add some mode bits to allow an initiator to choose
whether to let background tasks have priority over low power requests or
vice versa. I am not in favor of this concept.
Speaking for disk drives (other device classes may have a different
opinion), when we design background tasks they are for one reason -- to
increase the reliability of the disk drive. Let's be honest, background
tasks are a pain in the butt. They interfere with performance and power
savings, both of which are important to the customers. However the customers
also say that reliability is even more important than performance or power
savings.
My company will always want background tasks that ensure reliability to take
priority over low power conditions. All of my company's background tasks
fall into that category. Perhaps we can allow an initiator preference to
override background tasks that DO NOT enhance reliability. Then we end up
with a vendor specific interpretation of which background task might be
overridden and which ones are not, but I expect everyone will have
background tasks that are reliability related.
I think we are better off presuming background tasks are higher priority
than power savings and just leave it at that.


From Barry.Olawsky at hp.com  Wed Oct  7 21:18:40 2009
From: Barry.Olawsky at hp.com (Olawsky, Barry)
Date: Thu, 8 Oct 2009 04:18:40 +0000
Subject: SFF-8636/8449 discussion October 1 call information
Message-ID: <mailman.656.1441607350.22516.t10@sandbox.t10.org>

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

SFF- 8636 and SFF - 8449 contains information regarding the management
interface for the Mini SAS HD external cables. The weekly time slot for
discussing SAS PHY issues will be used to develop this publication.
Interested T10 members are invited and encouraged to participate.
USA Toll Free Dial in Number: (877)810-9442
International Access/Caller Paid Dial In Number: (636)651-3190
PARTICIPANT CODE: 3243413
WEBEX information:
Topic: SAS-2.1 PHY WG
Date: Thursday October 8
Time: 10:00 am, Central Time
Meeting Number: 826 515 680
Meeting Password: newsas


From curtis.stevens at wdc.com  Thu Oct  8 08:51:14 2009
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Oct 2009 08:51:14 -0700
Subject: UAS 09-339 Conference Call
Message-ID: <mailman.657.1441607350.22516.t10@sandbox.t10.org>

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

There were several bounce messages on the meeting update.  Please use the
following link to get the WebEx and dialin info:
https://wdc007.webex.com/wdc007/j.php?S=572890069 
If you are having problems with this link
1.	 Go To wdc007.webex.com
2.	 You should see the UAS meeting call on the screen
3.	 Click the Join link.  This will enter the conference.	Do not click
the meeting itself, this will send you to a place you don't want to go.
4.	 Audio conference information will be displayed.
VoIP is enabled for this conference.
-------------------------------------------------
Curtis E. Stevens
Sr. Staff  Engr - Standards & Features Technology
20511 Lake Forest Drive #A 113-F
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com  


From curtis.stevens at wdc.com  Thu Oct  8 11:10:23 2009
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 8 Oct 2009 11:10:23 -0700
Subject: UAS 09-339 Review
Message-ID: <mailman.658.1441607350.22516.t10@sandbox.t10.org>

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910081_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910081_meeting.ics">meeting.ics</a>

When: Thursday, October 15, 2009 10:00 AM-12:00 PM (UTC-08:00) Pacific Time
(US & Canada).
Where: WebEx
Note: The GMT offset above does not reflect daylight saving time
adjustments.
*~*~*~*~*~*~*~*~*~*
Short version of instructions...
Go To WDC007.WebEx.com and click the JOIN link for the UAS 09-339 Review
meeting.  Do not click the meeting link, this will not let you enter the
meeting.
Western Digital (Curtis) invites you to an online meeting using WebEx.
Meeting Number: 578 077 118
Meeting Password: This meeting does not require a password. 
-------------------------------------------------------
To join this meeting 
-------------------------------------------------------
1. Go to https://wdc007.webex.com/wdc007/j.php?J=578077118
2. Enter the meeting password: This meeting does not require a password. 
3. Click "Join Now".
4. Follow the instructions that appear on your screen.
-------------------------------------------------------
Audio conference information
-------------------------------------------------------
Call-in toll number (US/Canada): 1-408-792-6300
Global call-in numbers:
https://wdc007.webex.com/wdc007/globalcallin.php?serviceType=MC&ED=132170912
&tollFree=0
Access code:578 077 118
http://www.webex.com
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio
and any documents and other materials exchanged or viewed during the session
to be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, do not join the session.


From Wayne.Bellamy at hp.com  Thu Oct  8 11:52:08 2009
From: Wayne.Bellamy at hp.com (Bellamy, Wayne (mellow fellow))
Date: Thu, 8 Oct 2009 18:52:08 +0000
Subject: Comment on proposal 09-357r0
Message-ID: <mailman.659.1441607350.22516.t10@sandbox.t10.org>

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

After internal group discussions, it is our opinion at HP that a permission
bit be available in the START STOP UNIT command cdb that will allow (or
disallow) the device to transition from a reduced power state to an increased
power consumption state to perform internal device checks (background scans,
internal device calibrations, etc.). If it is acceptable to the host that
these device power consumption transitions occur, then the "permission" bit
would be set to one. If it is unacceptable to the host that these device
power consumption transitions occur, then the "permission" bit would be set
to zero.
It is our opinion that devices should not consume additional power at their
own discretion when "commanded" to enter into a lower power state. This may
not necessarily apply to the power condition timers, especially the "IDLE_A"
timer (minimal power change), although it seems that the same protocol should
be established for the timers (permission bit), also.
wayne
Wayne Bellamy
HP ESS ISS
wayne.bellamy at hp.com
281-514-5196
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark Evans
Sent: Wednesday, October 07, 2009 11:46 AM
To: Gerry.Houlder at seagate.com
Cc: t10 at t10.org
Subject: RE: Comment on proposal 09-357r0
Hi Gerry,
I'm working on clarifying the scenarios described in 09-357r0.	I've deleted
the scenario with the requirement for a two-bit field in concert with what
you wrote, as I agree that having different behaviors is too complicated,
and, at least for HDDs, we want to be able to process background tasks unless
this type of action has been specifically prohibited by a command from an
application client.  The following are my premises for this:
a)	  If a logical unit is in a low power state as the result of a
command (e.g., a START STOP UNIT command with the power condition field and
power condition modifier field set to cause the logical unit to transition to
the idle_a power condition), then the logical unit does not change state to
process background functions when timers or device-specific events occur;
and,
b)	 If a logical unit is in a low power state as the result of a power
condition timer expiring, then the logical unit changes state as necessary to
process background functions when timers or device-specific events occur.
Stay tuned.  I hope to have a new revision out this week with the goal being
that we discuss the new revision at CAP in November so I can get more input
before I make any specific proposed wording changes to draft standards.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
Office: 408.363.5257
Fax: 408.363.5139
Cell: 408.391.7805
Home: 408-746-3085
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Wednesday, October 07, 2009 8:33 AM
To: t10 at t10.org
Subject: Comment on proposal 09-357r0
Mark Evans recently posted proposal 09-357r0 (Relationship between low power
conditions and background tasks) and has asked for discussion of it on the
reflector. I'd like to offer my obervations.
I think the first four scenarios described in his proposal are sufficiently
described within the standards to arrive at these descriptions. The
descriptions are somewhat disk drive centric (e.g., giving special
consideration for START STOP UNIT and FORMAT comands) but I suspect these
same cases can be similary resolved for tape or other device classes with
similar device centric commands.
Scenario 5 proposes to add some mode bits to allow an initiator to choose
whether to let background tasks have priority over low power requests or vice
versa. I am not in favor of this concept.
Speaking for disk drives (other device classes may have a different opinion),
when we design background tasks they are for one reason -- to increase the
reliability of the disk drive. Let's be honest, background tasks are a pain
in the butt. They interfere with performance and power savings, both of which
are important to the customers. However the customers also say that
reliability is even more important than performance or power savings.
My company will always want background tasks that ensure reliability to take
priority over low power conditions. All of my company's background tasks fall
into that category. Perhaps we can allow an initiator preference to override
background tasks that DO NOT enhance reliability. Then we end up with a
vendor specific interpretation of which background task might be overridden
and which ones are not, but I expect everyone will have background tasks that
are reliability related.
I think we are better off presuming background tasks are higher priority than
power savings and just leave it at that.


From Mark.Evans at wdc.com  Thu Oct  8 13:05:11 2009
From: Mark.Evans at wdc.com (Mark Evans)
Date: Thu, 8 Oct 2009 13:05:11 -0700
Subject: Comment on proposal 09-357r0
Message-ID: <mailman.660.1441607350.22516.t10@sandbox.t10.org>

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

Hi Wayne,
I'd like to discuss this further to understand what HP wants.  I am
proposing that, if a logical unit is in a low power condition as the result
of receiving a START STOP UNIT command that requests that the logical unit
go to a low power mode (i.e., with the POWER CONDITION field set to 1h, 2h,
or 3h, or with the POWER CONDITION field set to 0h and the START bit set to
zero), then the logical unit NEVER leaves the low power condition to perform
a background task.  I think that, when a SCSI target device is commanded to
do something, the target device doesn't go off and do anything on its own,
ever.  I also thing that this makes a conditional bit in the CDB be
unnecessary for these modes.
I can see that a "permission" bit allowing or disallowing a logical unit to
leave a low power condition to perform background tasks when the logical
unit is in a low power condition as a result of a power condition timer
expiring provides an excellent option for application clients.	However, I
don't think this function should be in the CDB.  I think that, if there is
one, a permission bit should be in the Power Condition Mode page, with
support for the bit indicated in the Power Condition VPD page.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
________________________________
From: Bellamy, Wayne (mellow fellow) [mailto:Wayne.Bellamy at hp.com] 
Sent: Thursday, October 08, 2009 11:52 AM
To: Mark Evans; Gerry.Houlder at seagate.com
Cc: t10 at t10.org
Subject: RE: Comment on proposal 09-357r0
After internal group discussions, it is our opinion at HP that a permission
bit be available in the START STOP UNIT command cdb that will allow (or
disallow) the device to transition from a reduced power state to an
increased power consumption state to perform internal device checks
(background scans, internal device calibrations, etc.). If it is acceptable
to the host that these device power consumption transitions occur, then the
"permission" bit would be set to one. If it is unacceptable to the host that
these device power consumption transitions occur, then the "permission" bit
would be set to zero.
It is our opinion that devices should not consume additional power at their
own discretion when "commanded" to enter into a lower power state. This may
not necessarily apply to the power condition timers, especially the "IDLE_A"
timer (minimal power change), although it seems that the same protocol
should be established for the timers (permission bit), also.
wayne
Wayne Bellamy
HP ESS ISS
wayne.bellamy at hp.com
281-514-5196 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark Evans
Sent: Wednesday, October 07, 2009 11:46 AM
To: Gerry.Houlder at seagate.com
Cc: t10 at t10.org
Subject: RE: Comment on proposal 09-357r0
Hi Gerry,
I'm working on clarifying the scenarios described in 09-357r0.	I've deleted
the scenario with the requirement for a two-bit field in concert with what
you wrote, as I agree that having different behaviors is too complicated,
and, at least for HDDs, we want to be able to process background tasks
unless this type of action has been specifically prohibited by a command
|from an application client.  The following are my premises for this:
a)	  If a logical unit is in a low power state as the result of a
command (e.g., a START STOP UNIT command with the power condition field and
power condition modifier field set to cause the logical unit to transition
to the idle_a power condition), then the logical unit does not change state
to process background functions when timers or device-specific events occur;
and,
b)	 If a logical unit is in a low power state as the result of a power
condition timer expiring, then the logical unit changes state as necessary
to process background functions when timers or device-specific events occur.
Stay tuned.  I hope to have a new revision out this week with the goal being
that we discuss the new revision at CAP in November so I can get more input
before I make any specific proposed wording changes to draft standards.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com
Office: 408.363.5257
Fax: 408.363.5139
Cell: 408.391.7805
Home: 408-746-3085
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Wednesday, October 07, 2009 8:33 AM
To: t10 at t10.org
Subject: Comment on proposal 09-357r0
Mark Evans recently posted proposal 09-357r0 (Relationship between low power
conditions and background tasks) and has asked for discussion of it on the
reflector. I'd like to offer my obervations.
I think the first four scenarios described in his proposal are sufficiently
described within the standards to arrive at these descriptions. The
descriptions are somewhat disk drive centric (e.g., giving special
consideration for START STOP UNIT and FORMAT comands) but I suspect these
same cases can be similary resolved for tape or other device classes with
similar device centric commands.
Scenario 5 proposes to add some mode bits to allow an initiator to choose
whether to let background tasks have priority over low power requests or
vice versa. I am not in favor of this concept.
Speaking for disk drives (other device classes may have a different
opinion), when we design background tasks they are for one reason -- to
increase the reliability of the disk drive. Let's be honest, background
tasks are a pain in the butt. They interfere with performance and power
savings, both of which are important to the customers. However the customers
also say that reliability is even more important than performance or power
savings.
My company will always want background tasks that ensure reliability to take
priority over low power conditions. All of my company's background tasks
fall into that category. Perhaps we can allow an initiator preference to
override background tasks that DO NOT enhance reliability. Then we end up
with a vendor specific interpretation of which background task might be
overridden and which ones are not, but I expect everyone will have
background tasks that are reliability related.
I think we are better off presuming background tasks are higher priority
than power savings and just leave it at that.


From curtis.ballard at hp.com  Thu Oct  8 15:59:51 2009
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Thu, 8 Oct 2009 22:59:51 +0000
Subject: SMC-3 Working Group conference call 14 October, 8:00 AM PDT
Message-ID: <mailman.661.1441607350.22516.t10@sandbox.t10.org>

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

Hewlett Packard will host a teleconference for the SMC-3 working group on
Wednesday, 14 October at 8:00 AM PDT.  Contact details for that meeting
follow.
Please contact me for access numbers from any countries not listed.
The agenda follows this message and is available at:
http://www.t10.org/ftp/t10/smc-agnd.htm
Curtis Ballard
Hewlett Packard
-----------------------------------------
Conference Call Passcode:	8983013
Conference Call Access Numbers:
U.S. (toll) dial-in number		281.964.1607
U.S. toll-free dial-in number	877.675.4345
Germany 					069-22-221-6176 or
800-664-7543
Netherlands - Amsterdam 	020-714-3562 or 0800-023-5079
Norway - Oslo				21-033-192 or 800-18-430
United Kingdom				0844-579-0686 or 0808-238-0672
Virtual Rooms Link:	       
https://www.rooms.hp.com/attend/default.aspx?key=EHRM89XZLA
-----------------------------------------
Draft Agenda -- SCSI Media Changer
(SMC<http://www.t10.org/cgi-bin/ac.pl?t=f&f=smc-r10a.pdf&gt;) Working Group
Meeting
    Location -- Teleconference: 8-10 AM PDT 281-964-1607 or 877-675-4345, PIN
8983013
	Date -- 14 October, 2009
	Time -- 8:00 AM PDT
1.	Opening remarks and introductions
1.1	Antitrust Guidelines and INCITS Patent Policy
	(http://www.incits.org/pat_slides.pdf)
1.2	Meeting Documents
1.3	Introductions
2.	Approval of the Agenda
3.	Attendance and Membership
4.	Approval of previous meeting minutes
(09-338r1<http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-338r1.pdf&gt;)
5.	Review of action items
6.	Old Business
6.1	Working List for ISV feedback (SMC/SSC/ADC/SPC)
(07-131r1<http://www.t10.org/cgi-bin/ac.pl?t=d&f=07-131r1.pdf&gt;) [Butt]
6.2	SMC-3 TapeAlert Enhancements
(09-109r1<http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-109r1.pdf&gt;) [Ballard]
6.3	SMC-3 Report Volume Information
(08-215r6<http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-215r6.pdf&gt;) [Ballard]
6.4	SMC-3 New additional sense codes tracking document
(08-272r3<http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-272r3.pdf&gt;) [Wideman]
6.5	SMC-3 Use of element descriptor sense codes
(08-432r1<http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-432r1.pdf&gt;) [Snelder]
6.6	SMC-3 Move volume by indicator
(09-086r2<http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-086r2.pdf&gt;) [Snelder]
6.7	SMC-3: Controlling VTL Replication
(09-308r1<http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-308r1.pdf&gt;) [Cummings]
7.	New Business
9.	Next Meeting Requirements
10.	Review New Action Items
11.	Adjournment


From kdbutt at us.ibm.com  Fri Oct  9 12:31:35 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 9 Oct 2009 12:31:35 -0700
Subject: SPC-4: MAM Write-through cache bit (09-355r1)
Message-ID: <mailman.662.1441607350.22516.t10@sandbox.t10.org>

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

I have updated my proposal on write-through cache command for MAM
2009/10/09 13:30:14 
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=09-355r1.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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 Mark.Evans at wdc.com  Fri Oct  9 14:00:23 2009
From: Mark.Evans at wdc.com (Mark Evans)
Date: Fri, 9 Oct 2009 14:00:23 -0700
Subject: SPC-4, SBC-3 Relationship between power conditions and background tasks, 09-357r1
Message-ID: <mailman.663.1441607350.22516.t10@sandbox.t10.org>

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

Hello all,
I have uploaded to the T10 website a revision of my proposal based on the
summary of the relationships between power conditions and background tasks
that I originally constructed following the discussion after the SAS
Protocol working group at the T10 meeting in September (09-357r1).  I had
hoped to begin work on making proposed changes to text in the relevant
documents.  However, I see that just the summary is so involved, that I
think we need one more face-to-face meeting to discuss and agree upon the
summary before I consider any text modifications.
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at wdc.com


From lohmeyer at t10.org  Sat Oct 10 23:00:46 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 11 Oct 2009 00:00:46 -0600
Subject: Recent T10 documents uploaded since 2009/10/04
Message-ID: <mailman.664.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAT-3 Translation of idle and standby power condition commands
(by: Gerald Houlder)
T10/09-141r3   Uploaded: 2009/10/09   253428 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-141r3.pdf
UAS SCSI Procedure Calls
(by: Curtis Stevens)
T10/09-339r1   Uploaded: 2009/10/08   204568 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-339r1.pdf
SPC-4: MAM Write-through cache bit
(by: Kevin Butt)
T10/09-355r1   Uploaded: 2009/10/09   83084 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-355r1.pdf
SPC-4, SBC-3 Relationship between power conditions and background
tasks
(by: Mark Evans)
T10/09-357r1   Uploaded: 2009/10/09   48547 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-357r1.pdf
SPC-4 Conflicted List Format Log Parameter Rules
(by: Ralph Weber)
T10/09-359r0   Uploaded: 2009/10/06   74116 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-359r0.pdf
SPC-4 Log Page clean-up
(by: Ralph Weber)
T10/09-360r0   Uploaded: 2009/10/06   105410 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-360r0.pdf
SSC-4: Programmable Early Warning PEWS rounding
(by: Kevin Butt)
T10/09-361r0   Uploaded: 2009/10/06   56821 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-361r0.pdf
Working Drafts
--------------
SCSI Stream Commands - 4
(Editor: Dave Peterson)
 Rev: 00       Uploaded: 2009/10/08   3188854 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=ssc4r00.pdf
(Report generated on 2009/10/11 at 00:00:46)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Felton_Mickey at emc.com  Mon Oct 12 13:36:44 2009
From: Felton_Mickey at emc.com (Felton_Mickey at emc.com)
Date: Mon, 12 Oct 2009 16:36:44 -0400
Subject: Block Reads on 2-Wire miniSAS HD Management Interface
Message-ID: <mailman.665.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <Felton_Mickey at emc.com>
*
Barry/T10:
Another question I had was on the I2C address for the common interface,
will it be the same as QSFP today?
Are there any benefits to some other strategy/address?
Thanks!
-Mick
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Olawsky,
Barry
Sent: Friday, July 31, 2009 2:58 PM
To: t10 at t10.org
Subject: Block Reads on 2-Wire miniSAS HD Management Interface
* From the T10 Reflector (t10 at t10.org), posted by:
* "Olawsky, Barry" <Barry.Olawsky at hp.com>
*
In response to the "block read" question posed during the PHY meeting on
7/30/2009, virtually all 2-wire serial EEPROM devices currently
available support sequential reads (block reads). 
Adding the requirement for sequential read support may not appear
necessary for discrete EEPROM implementations but is probably prudent
for micro-controller implementations. For the latter, existing 2-wire
interface cores lacking support for sequential reads may end up being
used due to cost or availability of an existing core design. Explicitly
defining sequential read and write operations should prevent that from
occurring.
I recommend including this requirement in the timing diagram section of
the SFF QSFP document. Timing of the serial data line state determines
if the access is sequential or single byte.
*
* 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 Barry.Olawsky at hp.com  Mon Oct 12 15:26:15 2009
From: Barry.Olawsky at hp.com (Olawsky, Barry)
Date: Mon, 12 Oct 2009 22:26:15 +0000
Subject: Block Reads on 2-Wire miniSAS HD Management Interface
Message-ID: <mailman.666.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Olawsky, Barry" <Barry.Olawsky at hp.com>
*
It is the plan for the 2-wire interface to be identical. However, there does
appear to be a discrepancy in the block write definition. The read operation
definition is consistent with available devices. More on Thursday morning.
-----Original Message-----
From: Felton_Mickey at emc.com [mailto:Felton_Mickey at emc.com] 
Sent: Monday, October 12, 2009 3:37 PM
To: Olawsky, Barry; t10 at t10.org
Subject: RE: Block Reads on 2-Wire miniSAS HD Management Interface
Barry/T10:
Another question I had was on the I2C address for the common interface,
will it be the same as QSFP today?
Are there any benefits to some other strategy/address?
Thanks!
-Mick
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Olawsky,
Barry
Sent: Friday, July 31, 2009 2:58 PM
To: t10 at t10.org
Subject: Block Reads on 2-Wire miniSAS HD Management Interface
* From the T10 Reflector (t10 at t10.org), posted by:
* "Olawsky, Barry" <Barry.Olawsky at hp.com>
*
In response to the "block read" question posed during the PHY meeting on
7/30/2009, virtually all 2-wire serial EEPROM devices currently
available support sequential reads (block reads). 
Adding the requirement for sequential read support may not appear
necessary for discrete EEPROM implementations but is probably prudent
for micro-controller implementations. For the latter, existing 2-wire
interface cores lacking support for sequential reads may end up being
used due to cost or availability of an existing core design. Explicitly
defining sequential read and write operations should prevent that from
occurring.
I recommend including this requirement in the timing diagram section of
the SFF QSFP document. Timing of the serial data line state determines
if the access is sequential or single byte.
*
* 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 jmcgrath at email.cinch.com  Mon Oct 12 20:25:10 2009
From: jmcgrath at email.cinch.com (McGrath, James)
Date: Mon, 12 Oct 2009 22:25:10 -0500
Subject: Block Reads on 2-Wire miniSAS HD Management Interface
Message-ID: <mailman.667.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "McGrath, James" <jmcgrath at email.cinch.com>
*
Mick, anything T10 decides for QSFP must be compatible with the current
memory map described in SFF8436. There are areas of the memory map that
could be modified without effecting the current registers. But we need
to make sure anything we do for SAS does not create an incompatibility
problem for all the QSFP+ cables in data centers today. 
Jim McGrath
Cinch Connectors
1700 Finley Road
Lombard, IL 60148
office: 630-693-2040
mobile: 630-244-3872
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Felton_Mickey at emc.com
Sent: Monday, October 12, 2009 3:37 PM
To: Barry.Olawsky at hp.com; t10 at t10.org
Subject: RE: Block Reads on 2-Wire miniSAS HD Management Interface
* From the T10 Reflector (t10 at t10.org), posted by:
* <Felton_Mickey at emc.com>
*
Barry/T10:
Another question I had was on the I2C address for the common interface,
will it be the same as QSFP today?
Are there any benefits to some other strategy/address?
Thanks!
-Mick
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Olawsky,
Barry
Sent: Friday, July 31, 2009 2:58 PM
To: t10 at t10.org
Subject: Block Reads on 2-Wire miniSAS HD Management Interface
* From the T10 Reflector (t10 at t10.org), posted by:
* "Olawsky, Barry" <Barry.Olawsky at hp.com>
*
In response to the "block read" question posed during the PHY meeting on
7/30/2009, virtually all 2-wire serial EEPROM devices currently
available support sequential reads (block reads). 
Adding the requirement for sequential read support may not appear
necessary for discrete EEPROM implementations but is probably prudent
for micro-controller implementations. For the latter, existing 2-wire
interface cores lacking support for sequential reads may end up being
used due to cost or availability of an existing core design. Explicitly
defining sequential read and write operations should prevent that from
occurring.
I recommend including this requirement in the timing diagram section of
the SFF QSFP document. Timing of the serial data line state determines
if the access is sequential or single byte.
*
* 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
The information contained in this electronic mail message is 
privileged and confidential information, may be subject to the 
attorney-client privilege and is intended solely for the use of 
the addressee. If you are not the intended recipient, any 
disclosure, copying, distribution, or the taking of any action 
in reliance on the contents of this message is strictly 
prohibited. If you have received this message in error, please 
notify me immediately. 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Tue Oct 13 09:50:16 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 13 Oct 2009 09:50:16 -0700
Subject: SSC-4: Append-only mode
Message-ID: <mailman.668.1441607350.22516.t10@sandbox.t10.org>

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

I have updated my proposal for an append-only mode.
2009/10/13 10:13:13 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-356r3.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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 kdbutt at us.ibm.com  Tue Oct 13 09:45:23 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 13 Oct 2009 09:45:23 -0700
Subject: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
Message-ID: <mailman.669.1441607350.22516.t10@sandbox.t10.org>

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

T10 Security experts,
I am receiving requests to clarify what is intended for the key exchange 
data field in the key exchange payload for the D-H portion of IKEv2-SCSI. 
I must admit I cannot figure it out.  We always get wrapped around the 
wording, " The format of key exchange data is as specified in the 
reference cited in that registry for the value used"  What is the 
reference cited and what is the registry?  Then, since the term format is 
used, it leads one to believe there is something more than just a public 
key.
Here is a note I received that highlights the confusion:
Is the key data field of the .key exchange payload is simply the public 
key from the agreed upon D-H group? What makes this confusing is the SPC-4 
standard in section 7.6.3.5.3 Key Exchange Payload which states 
The KEY EXCHANGE DATA field contains the sender?s Diffie-Hellman public 
value for this key exchange. The format of
key exchange data is as specified in the reference cited in that registry 
for the value used.
The question of the format is to be used is not clear since it is not 
clear what the reference cited is.This still bugs me. If this field is 
simply the public key (with prepended zeros to pad to the length of the 
prime modulus (if that function was chosen), why not just say that. 
Mentioning a format makes it sound like there is more to it. Now in 
http://tools.ietf.org/html/rfc4753 there is a mention of using a KE format 
for ECP group generated public key in section 7. In the section which 
follows there are some examples. In these examples there are 2 DWORDs 
preceding the public key. The first is the number of bytes of the payload. 
The second is the group number in the upper half of the DWORD. In 
http://tools.ietf.org/html/rfc2408, the Internet Security Association and 
Key Management Protocol (ISAKMP), section 3.7 defines the key exchange 
payload which includes a Key Exchange Data field. Again, it seems this 
field depends on the D-H group. although this (ISAKMP) standard is more 
general. 
So, does the format then depend on which D-H group is being used? Just the 
public key if it's a mod P group, and the public key preceded by these two 
DWORDs if it's an ECP group?
My questions are:
1) Is the answer, Just the public key if it's a mod P group?
2) What can be done in SPC-4 to clear up the confusion?  Can this be more 
detailed or can there be an example added?
thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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 lohmeyer at t10.org  Tue Oct 13 14:40:19 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 13 Oct 2009 15:40:19 -0600
Subject: Fwd: For Distribution to INCITS/T10:  CALL FOR VOLUNTEERS -
  International Representative - INCITS/T10, SCSI Storage Interfaces -
  Closes November 12, 2009
Message-ID: <mailman.670.1441607350.22516.t10@sandbox.t10.org>

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

The term for T10 International Representative is three years. Gary can apply
again. I don't know whether (or not) he plans to do so. If you have any other
questions, please contact me. -- John
>From: "Garner, Jennifer" <jgarner at itic.org>
>To: "Lohmeyer, John" <lohmeyer at t10.org>
>CC: "Robinson, Gary" <g.robinson at computer.org>, "Patrick, Serena"
>	 <spatrick at itic.org>, "Barra, Lynn" <lbarra at itic.org>
>Date: Tue, 13 Oct 2009 14:17:49 -0600
>Subject: For Distribution to INCITS/T10:  CALL FOR VOLUNTEERS -
> International Representative - INCITS/T10, SCSI Storage Interfaces - Closes
> November 12, 2009
>
>John ?
> 
>Gary Robinson?s current term as INCITS/T10 (SCSI Storage Interfaces)
International Representative will expire in March 2010.  At your earliest
opportunity, please distribute the attached call for volunteers to serve as
INCITS/T10 International Representative to the members of your committee.
> 
>I will be in touch after the call has closed on November 12, 2009.
> 
>Best regards -
> 
> 
>NOTE:	New mailing address effective June 1, 2009
>Jennifer T. Garner
>Director, Standards Programs
>INCITS/Information Technology Industry Council
>1101 K Street NW  Suite 610
>Washington, DC 20005
>T:   202.626.5737
>E:   jgarner at itic.org
>W:  <www.incits.org">http://www.incits.org>www.incits.org
> 
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907


From George.Penokie at lsi.com  Tue Oct 13 14:53:26 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 13 Oct 2009 15:53:26 -0600
Subject: FW: (Forward to attendees) Meeting invitation: SPL extended buffer
 support
Message-ID: <mailman.671.1441607350.22516.t10@sandbox.t10.org>

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

A reminder that there will be a SPL call on 10/14. Call-in and WebEx info
below.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
From: George Penokie [mailto:messenger at webex.com]
Sent: Thursday, September 17, 2009 10:39 AM
To: Penokie, George
Subject: (Forward to attendees) Meeting invitation: SPL extended buffer
support
**** You can forward this email invitation to attendees ****
Hello ,
George Penokie invites you to attend this online meeting.
Topic: SPL extended buffer support
Date: Wednesday, October 14, 2009
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago)
Meeting Number: 578 252 323
Meeting Password: Buffer1
Please click the link below to see more information, or to join the meeting.
-------------------------------------------------------
To join the online meeting (Now from iPhones too!)
-------------------------------------------------------
1. Go to
https://lsilogic.webex.com/lsilogic/j.php?ED=130785982&UID=0&PW=df878462a1311
10c55515f42
2. Enter your name and email address.
3. Enter the meeting password: Buffer1
4. Click "Join Now".
-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Conference Access:
  Toll free:  1-800-531-5745
  Toll:       1-719-955-2349
Passcode:     5073289017
-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://lsilogic.webex.com/lsilogic/mc
2. On the left navigation bar, click "Support".
You can contact me at:
george.penokie at lsi.com
1-507-3289017
To add this meeting to your calendar program (for example Microsoft Outlook),
click this link:
https://lsilogic.webex.com/lsilogic/j.php?ED=130785982&UID=0&ICS=MI&LD=1&RD=2
&ST=1&SHA2=Ph4revDz1DsMQNlA4DxKrvIFuFk4Y536n13RsemWd4w=
The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in the
meeting, please check whether you have the players installed on your computer
by going to https://lsilogic.webex.com/lsilogic/systemdiagnosis.php
Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial
http://www.webex.com
We've got to start meeting like this(TM)
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, do not join the session.


From Black_David at emc.com  Tue Oct 13 16:08:25 2009
From: Black_David at emc.com (Black_David at emc.com)
Date: Tue, 13 Oct 2009 19:08:25 -0400
Subject: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
Message-ID: <mailman.672.1441607350.22516.t10@sandbox.t10.org>

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

Kevin,
> The question of the format is to be used is not clear since it is not
clear what the reference cited is.
> This still bugs me. If this field is simply the public key (with
prepended zeros to pad to the length of
> the prime modulus (if that function was chosen), why not just say
that.
For a mod-P group, that's exactly what it is.  For ECP, the answer is a
more complex form of "yes" because the representation turns out to be
partially implicit.
> Now in http://tools.ietf.org/html/rfc4753
<http://tools.ietf.org/html/rfc4753&gt;  there is a mention of using a KE
format for ECP group generated
> public key in section 7. In the section which follows there are some
examples.
Unfortunately, RFC 4753 got it wrong - there's a very important erratum
that
invalidates all of its examples - only the x value is passed, not both
the
x and y values, see:
http://www.rfc-editor.org/errata_search.php?rfc=4753
We will need to fix this in SPC-4.
> In these examples there are 2 DWORDs preceding the public key.  The
first is the number of bytes
> of the payload. The second is the group number in the upper half of
the DWORD.
Not exactly - those examples are complete IKE KEi and KEr payloads, so
they contain the entire payload headers, with the NEXT PAYLOAD field
set to zero in each case for the purpose of the example.  For
IKEv2-SCSI,
these payload headers are specified as bytes 0-7 in table 427 (SPC-4 rev
21).
> So, does the format then depend on which D-H group is being used?
Yes and no:
- Yes, you have to know whether it's a mod P group vs. an ECP group in
    order to figure out what to do with the key exchange material.
    Trying to use a mod-P DH value as an ECP x coordinate or vice-versa
    is not going to work very well :-).
- No, the payload format is common; headers plus key exchange material.
> Just the public key if it's a mod P group, and the public key preceded
by these two DWORDs if it's an ECP group?
No, it's always the "public key".  The two DWORDS are payload headers
that are already specified in SPC-4 Table 427.
> My questions are: 
> 1) Is the answer, Just the public key if it's a mod P group?
Yes.
> 2) What can be done in SPC-4 to clear up the confusion?  Can this be
more detailed or can there be an example added?
At the very least, we need to fix the mistake in RFC 4753.  If we
changed
"format" to "binary representation" would that help?
Thanks,
--David
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Tuesday, October 13, 2009 12:45 PM
	To: t10 at t10.org
	Subject: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
	T10 Security experts, 
	I am receiving requests to clarify what is intended for the key
exchange data field in the key exchange payload for the D-H portion of
IKEv2-SCSI.  I must admit I cannot figure it out.  We always get wrapped
around the wording, " The format of key exchange data is as specified in
the reference cited in that registry for the value used"  What is the
reference cited and what is the registry?  Then, since the term format
is used, it leads one to believe there is something more than just a
public key. 
	Here is a note I received that highlights the confusion: 
	Is the key data field of the .key exchange payload is simply the
public key from the agreed upon D-H group? What makes this confusing is
the SPC-4 standard in section 7.6.3.5.3 Key Exchange Payload which
states 
	The KEY EXCHANGE DATA field contains the sender's Diffie-Hellman
public value for this key exchange. The format of 
	key exchange data is as specified in the reference cited in that
registry for the value used. 
	The question of the format is to be used is not clear since it
is not clear what the reference cited is.This still bugs me. If this
field is simply the public key (with prepended zeros to pad to the
length of the prime modulus (if that function was chosen), why not just
say that. Mentioning a format makes it sound like there is more to it.
Now in http://tools.ietf.org/html/rfc4753
<http://tools.ietf.org/html/rfc4753&gt;  there is a mention of using a KE
format for ECP group generated public key in section 7. In the section
which follows there are some examples. In these examples there are 2
DWORDs preceding the public key. The first is the number of bytes of the
payload. The second is the group number in the upper half of the DWORD.
In http://tools.ietf.org/html/rfc2408
<http://tools.ietf.org/html/rfc2408&gt; , the Internet Security Association
and Key Management Protocol (ISAKMP), section 3.7 defines the key
exchange payload which includes a Key Exchange Data field. Again, it
seems this field depends on the D-H group. although this (ISAKMP)
standard is more general. 
	So, does the format then depend on which D-H group is being
used? Just the public key if it's a mod P group, and the public key
preceded by these two DWORDs if it's an ECP group? 
	My questions are: 
	1) Is the answer, Just the public key if it's a mod P group? 
	2) What can be done in SPC-4 to clear up the confusion?  Can
this be more detailed or can there be an example added? 
	thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	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/
<http://www-03.ibm.com/servers/storage/&gt;  


From kdbutt at us.ibm.com  Tue Oct 13 16:31:27 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 13 Oct 2009 16:31:27 -0700
Subject: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
Message-ID: <mailman.673.1441607350.22516.t10@sandbox.t10.org>

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

David,
Thank you for your reply.  If I read what you said correctly, then the 
value for the ECP group would also be the public key.  But I think I am 
missing something because that doesn't make sense that they are both the 
same thing and we don't state that straight out in SPC-4.
As for the wording change, changing "format" to "binary representation" 
makes the text read
>>>
The KEY EXCHANGE DATA field contains the sender?s Diffie-Hellman public 
value for this key exchange. The <binary representation> of key exchange 
data is as specified in the reference cited in that registry for the value 
used."
>>>>
This still leaves me hanging on what "the reference cited in that registry 
for the value used" is referring to.
This sounds like a double or triple indirection and it is not very clear.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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:
<Black_David at emc.com>
To:
Kevin D Butt/Tucson/IBM at IBMUS, <t10 at t10.org>
Date:
10/13/2009 04:10 PM
Subject:
RE: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
Kevin,
> The question of the format is to be used is not clear since it is not 
clear what the reference cited is.
> This still bugs me. If this field is simply the public key (with 
prepended zeros to pad to the length of
> the prime modulus (if that function was chosen), why not just say that.
For a mod-P group, that's exactly what it is.  For ECP, the answer is a
more complex form of "yes" because the representation turns out to be
partially implicit.
> Now in http://tools.ietf.org/html/rfc4753 there is a mention of using a 
KE format for ECP group generated
> public key in section 7. In the section which follows there are some 
examples.
Unfortunately, RFC 4753 got it wrong - there's a very important erratum 
that
invalidates all of its examples - only the x value is passed, not both the
x and y values, see:
http://www.rfc-editor.org/errata_search.php?rfc=4753
We will need to fix this in SPC-4.
> In these examples there are 2 DWORDs preceding the public key.  The 
first is the number of bytes
> of the payload. The second is the group number in the upper half of the 
DWORD.
Not exactly - those examples are complete IKE KEi and KEr payloads, so
they contain the entire payload headers, with the NEXT PAYLOAD field
set to zero in each case for the purpose of the example.  For IKEv2-SCSI,
these payload headers are specified as bytes 0-7 in table 427 (SPC-4 rev 
21).
> So, does the format then depend on which D-H group is being used?
Yes and no:
- Yes, you have to know whether it's a mod P group vs. an ECP group in
    order to figure out what to do with the key exchange material.
    Trying to use a mod-P DH value as an ECP x coordinate or vice-versa
    is not going to work very well :-).
- No, the payload format is common; headers plus key exchange material.
> Just the public key if it's a mod P group, and the public key preceded 
by these two DWORDs if it's an ECP group?
No, it's always the "public key".  The two DWORDS are payload headers
that are already specified in SPC-4 Table 427.
> My questions are: 
> 1) Is the answer, Just the public key if it's a mod P group?
Yes.
> 2) What can be done in SPC-4 to clear up the confusion?  Can this be 
more detailed or can there be an example added?
At the very least, we need to fix the mistake in RFC 4753.  If we changed
"format" to "binary representation" would that help?
Thanks,
--David
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Tuesday, October 13, 2009 12:45 PM
To: t10 at t10.org
Subject: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
T10 Security experts, 
I am receiving requests to clarify what is intended for the key exchange 
data field in the key exchange payload for the D-H portion of IKEv2-SCSI. 
I must admit I cannot figure it out.  We always get wrapped around the 
wording, " The format of key exchange data is as specified in the 
reference cited in that registry for the value used"  What is the 
reference cited and what is the registry?  Then, since the term format is 
used, it leads one to believe there is something more than just a public 
key. 
Here is a note I received that highlights the confusion: 
Is the key data field of the .key exchange payload is simply the public 
key from the agreed upon D-H group? What makes this confusing is the SPC-4 
standard in section 7.6.3.5.3 Key Exchange Payload which states 
The KEY EXCHANGE DATA field contains the sender?s Diffie-Hellman public 
value for this key exchange. The format of 
key exchange data is as specified in the reference cited in that registry 
for the value used. 
The question of the format is to be used is not clear since it is not 
clear what the reference cited is.This still bugs me. If this field is 
simply the public key (with prepended zeros to pad to the length of the 
prime modulus (if that function was chosen), why not just say that. 
Mentioning a format makes it sound like there is more to it. Now in 
http://tools.ietf.org/html/rfc4753 there is a mention of using a KE format 
for ECP group generated public key in section 7. In the section which 
follows there are some examples. In these examples there are 2 DWORDs 
preceding the public key. The first is the number of bytes of the payload. 
The second is the group number in the upper half of the DWORD. In 
http://tools.ietf.org/html/rfc2408, the Internet Security Association and 
Key Management Protocol (ISAKMP), section 3.7 defines the key exchange 
payload which includes a Key Exchange Data field. Again, it seems this 
field depends on the D-H group. although this (ISAKMP) standard is more 
general. 
So, does the format then depend on which D-H group is being used? Just the 
public key if it's a mod P group, and the public key preceded by these two 
DWORDs if it's an ECP group? 
My questions are: 
1) Is the answer, Just the public key if it's a mod P group? 
2) What can be done in SPC-4 to clear up the confusion?  Can this be more 
detailed or can there be an example added? 
thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
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 Black_David at emc.com  Tue Oct 13 17:21:33 2009
From: Black_David at emc.com (Black_David at emc.com)
Date: Tue, 13 Oct 2009 20:21:33 -0400
Subject: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
Message-ID: <mailman.674.1441607350.22516.t10@sandbox.t10.org>

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

Kevin,
To be precise, what's actually exchanged is key exchange material.
Whether
that material is actually a public key is a potential matter of
hair-splitting,
as *if* one wants to view it as a member of a key pair, that key pair is
usually ephemeral and in particular, the key is not associated with any
identity
(e.g., the key exchange material is not being used to establish
authentication).
FWIW, the security community does not generally view an ephemeral DH
exchange
(at least the mod-P variety) as involving key pairs.
I think I just "won" an action to write a proposal for November that:
- Changes "format" to "binary representation" in the crucial location.
- Corrects the ECP key binary representation mistake in RFC 4753.
- Makes the vague reference to "registry" more precise (at the very
least
    a Table number and column header are called for).
I'm unlikely to use the phrase "public key" in that proposal ;-).
Thanks,
--David
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Tuesday, October 13, 2009 7:31 PM
	To: Black, David; Tim Johnson; David L Swanson; Lou Dickens
	Cc: t10 at t10.org
	Subject: RE: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
	David, 
	Thank you for your reply.  If I read what you said correctly,
then the value for the ECP group would also be the public key.	But I
think I am missing something because that doesn't make sense that they
are both the same thing and we don't state that straight out in SPC-4. 
	As for the wording change, changing "format" to "binary
representation" makes the text read 
	>>> 
	The KEY EXCHANGE DATA field contains the sender's Diffie-Hellman
public value for this key exchange. The <binary representation> of key
exchange data is as specified in the reference cited in that registry
for the value used." 
	>>>> 
	This still leaves me hanging on what "the reference cited in
that registry for the value used" is referring to. 
	This sounds like a double or triple indirection and it is not
very clear. 
	Thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	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/
<http://www-03.ibm.com/servers/storage/&gt;  
From:	<Black_David at emc.com> 
To:	Kevin D Butt/Tucson/IBM at IBMUS, <t10 at t10.org> 
Date:	10/13/2009 04:10 PM 
Subject:	RE: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
________________________________
	Kevin, 
	> The question of the format is to be used is not clear since it
is not clear what the reference cited is.
	> This still bugs me. If this field is simply the public key
(with prepended zeros to pad to the length of
	> the prime modulus (if that function was chosen), why not just
say that. 
	For a mod-P group, that's exactly what it is.  For ECP, the
answer is a
	more complex form of "yes" because the representation turns out
to be
	partially implicit. 
	> Now in http://tools.ietf.org/html/rfc4753
<http://tools.ietf.org/html/rfc4753&gt;  there is a mention of using a KE
format for ECP group generated
	> public key in section 7. In the section which follows there
are some examples. 
	Unfortunately, RFC 4753 got it wrong - there's a very important
erratum that
	invalidates all of its examples - only the x value is passed,
not both the
	x and y values, see: 
	http://www.rfc-editor.org/errata_search.php?rfc=4753
<http://www.rfc-editor.org/errata_search.php?rfc=4753&gt;	
	We will need to fix this in SPC-4. 
	> In these examples there are 2 DWORDs preceding the public key.
The first is the number of bytes
	> of the payload. The second is the group number in the upper
half of the DWORD. 
	Not exactly - those examples are complete IKE KEi and KEr
payloads, so
	they contain the entire payload headers, with the NEXT PAYLOAD
field
	set to zero in each case for the purpose of the example.  For
IKEv2-SCSI,
	these payload headers are specified as bytes 0-7 in table 427
(SPC-4 rev 21). 
	> So, does the format then depend on which D-H group is being
used? 
	Yes and no:
	- Yes, you have to know whether it's a mod P group vs. an ECP
group in
	   order to figure out what to do with the key exchange
material.
	   Trying to use a mod-P DH value as an ECP x coordinate or
vice-versa
	   is not going to work very well :-).
	- No, the payload format is common; headers plus key exchange
material. 
	> Just the public key if it's a mod P group, and the public key
preceded by these two DWORDs if it's an ECP group? 
	No, it's always the "public key".  The two DWORDS are payload
headers
	that are already specified in SPC-4 Table 427. 
	> My questions are: 
	> 1) Is the answer, Just the public key if it's a mod P group?
	Yes. 
	> 2) What can be done in SPC-4 to clear up the confusion?  Can
this be more detailed or can there be an example added?
	At the very least, we need to fix the mistake in RFC 4753.  If
we changed
	"format" to "binary representation" would that help? 
	Thanks,
	--David 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org
<mailto:owner-t10 at t10.org> ] On Behalf Of Kevin D Butt
	Sent: Tuesday, October 13, 2009 12:45 PM
	To: t10 at t10.org
	Subject: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
	T10 Security experts, 
	I am receiving requests to clarify what is intended for the key
exchange data field in the key exchange payload for the D-H portion of
IKEv2-SCSI.  I must admit I cannot figure it out.  We always get wrapped
around the wording, " The format of key exchange data is as specified in
the reference cited in that registry for the value used"  What is the
reference cited and what is the registry?  Then, since the term format
is used, it leads one to believe there is something more than just a
public key. 
	Here is a note I received that highlights the confusion: 
	Is the key data field of the .key exchange payload is simply the
public key from the agreed upon D-H group? What makes this confusing is
the SPC-4 standard in section 7.6.3.5.3 Key Exchange Payload which
states 
	The KEY EXCHANGE DATA field contains the sender's Diffie-Hellman
public value for this key exchange. The format of 
	key exchange data is as specified in the reference cited in that
registry for the value used. 
	The question of the format is to be used is not clear since it
is not clear what the reference cited is.This still bugs me. If this
field is simply the public key (with prepended zeros to pad to the
length of the prime modulus (if that function was chosen), why not just
say that. Mentioning a format makes it sound like there is more to it.
Now in http://tools.ietf.org/html/rfc4753
<http://tools.ietf.org/html/rfc4753&gt;  there is a mention of using a KE
format for ECP group generated public key in section 7. In the section
which follows there are some examples. In these examples there are 2
DWORDs preceding the public key. The first is the number of bytes of the
payload. The second is the group number in the upper half of the DWORD.
In http://tools.ietf.org/html/rfc2408
<http://tools.ietf.org/html/rfc2408&gt; , the Internet Security Association
and Key Management Protocol (ISAKMP), section 3.7 defines the key
exchange payload which includes a Key Exchange Data field. Again, it
seems this field depends on the D-H group. although this (ISAKMP)
standard is more general. 
	So, does the format then depend on which D-H group is being
used? Just the public key if it's a mod P group, and the public key
preceded by these two DWORDs if it's an ECP group? 
	My questions are: 
	1) Is the answer, Just the public key if it's a mod P group? 
	2) What can be done in SPC-4 to clear up the confusion?  Can
this be more detailed or can there be an example added? 
	thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	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/
<http://www-03.ibm.com/servers/storage/&gt;  


From keiji_katata at post.pioneer.co.jp  Wed Oct 14 22:51:15 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 15 Oct 2009 14:51:15 +0900
Subject: Posted: Draft Meeting Minutes of 10/15, new activity notice
Message-ID: <mailman.675.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted Draft Meeting Minutes on ftp.
 ftp.avc-pioneer.com/Mtfuji_7/Minutes/DraftMin1015.pdf
Today, Fuji group decided that Group starts an activity for Zero Power ODD
effort.
Please refer to the Meeting Minutes.
I would like to propose to establish a sub-working group for drafting an
annex.
Because in the case of plenary meeting, we need 3 weeks before the meeting.
The date of the SWG meeting, it should be after 10/21 (Japan time) to wait
the
examination of Brian's document.
If you have an idea for the SWG meeting, please send to reflector or me.
Best regards,
Keiji Katata
PIONEER CORP.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Chris.Fore at netapp.com  Thu Oct 15 08:03:00 2009
From: Chris.Fore at netapp.com (Fore, Chris)
Date: Thu, 15 Oct 2009 11:03:00 -0400
Subject: SAS PHy WG call today? 
Message-ID: <mailman.676.1441607350.22516.t10@sandbox.t10.org>

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

Is there a SAS PHY WG call today? 
If so, then can someone please send WebEx / Teleconference details to
the reflector? 
- Chris 
R. Chris Fore
Senior Engineer
CSPG - Storage Product Unit
NetApp
919.476.5155 Direct
Chris.Fore at netapp.com
 www.netapp.com <http://www.netapp.com&gt; 


From Barry.Olawsky at hp.com  Thu Oct 15 08:10:04 2009
From: Barry.Olawsky at hp.com (Olawsky, Barry)
Date: Thu, 15 Oct 2009 15:10:04 +0000
Subject: SAS PHy WG call today? 
Message-ID: <mailman.677.1441607350.22516.t10@sandbox.t10.org>

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

Yes, there is. I didn't get the announcement out this week.
USA Toll Free Dial in Number: (877)810-9442
International Access/Caller Paid Dial In Number: (636)651-3190
PARTICIPANT CODE: 3243413
WEBEX information:
Topic: SAS-2.1 PHY WG
Date: Thursday
Time: 10:00 am, Central Time
Meeting Number: 826 515 680
Meeting Password: newsas
From: Fore, Chris [mailto:Chris.Fore at netapp.com]
Sent: Thursday, October 15, 2009 10:03 AM
To: t10 at t10.org
Cc: Olawsky, Barry
Subject: SAS PHy WG call today?
Is there a SAS PHY WG call today?
If so, then can someone please send WebEx / Teleconference details to the
reflector?
- Chris
R. Chris Fore
Senior Engineer
CSPG - Storage Product Unit
NetApp
919.476.5155 Direct
Chris.Fore at netapp.com
www.netapp.com<<a href="http://www.netapp.com&gt">http://www.netapp.com&gt;
[cid:image001.jpg at 01CA4D7F.AA20C4A0]


From George.Penokie at lsi.com  Thu Oct 15 12:11:20 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Thu, 15 Oct 2009 13:11:20 -0600
Subject: Meeting invitation: SPL proposals review
Message-ID: <mailman.678.1441607350.22516.t10@sandbox.t10.org>

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

There will be a conference call on 10/28 from 10-12 CT (see call-in and WebEx
information below) o discussion the following SPL proposals:
09-358r0 SPL - Zone Persistence Fix
09-268r3 SPL - STP extended buffer support
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
From: George Penokie [mailto:messenger at webex.com]
Sent: Thursday, October 15, 2009 2:07 PM
To: Penokie, George
Subject: (Forward to attendees) Meeting invitation: SPL proposals review
**** You can forward this email invitation to attendees ****
Hello ,
George Penokie invites you to attend this online meeting.
Topic: SPL proposals review
Date: Wednesday, October 28, 2009
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago)
Meeting Number: 571 472 131
Meeting Password: Buffer01
Please click the link below to see more information, or to join the meeting.
-------------------------------------------------------
To join the online meeting (Now from iPhones too!)
-------------------------------------------------------
1. Go to
https://lsilogic.webex.com/lsilogic/j.php?ED=132558402&UID=0&PW=7703f8b9486e1
b1c1e065e5d5f
2. Enter your name and email address.
3. Enter the meeting password: Buffer01
4. Click "Join Now".
-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Conference Access:
  Toll free:  1-866-214-7945
  Toll:       1-702-696-4029
Passcode:     5073289017
-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://lsilogic.webex.com/lsilogic/mc
2. On the left navigation bar, click "Support".
You can contact me at:
george.penokie at lsi.com
1-507-3289017
To add this meeting to your calendar program (for example Microsoft Outlook),
click this link:
https://lsilogic.webex.com/lsilogic/j.php?ED=132558402&UID=0&ICS=MI&LD=1&RD=2
&ST=1&SHA2=GuOmtLUepjM0E7faUG6pte6rYeH1OpBc4m9bNmTAuto=
The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in the
meeting, please check whether you have the players installed on your computer
by going to https://lsilogic.webex.com/lsilogic/systemdiagnosis.php
Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial
http://www.webex.com
We've got to start meeting like this(TM)
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, do not join the session.


From Daniel.Colegrove at hitachigst.com  Thu Oct 15 14:27:07 2009
From: Daniel.Colegrove at hitachigst.com (Daniel.Colegrove at hitachigst.com)
Date: Thu, 15 Oct 2009 14:27:07 -0700
Subject: T10 November Hotel Reservation Final Reminder  
Message-ID: <mailman.679.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Daniel.Colegrove at hitachigst.com
*
The cut off date for the November meeting is Monday (October 19th). The
room block has rooms remaining. Please make your reservations if you
have not done so. Thanks to all those who have.
Note: The hotel requires a deposit the time the reservation is made of
approximately $150, as is annoyingly common with resort hotels.
Meeting Announcement:
http://www.t10.org/ftp/t10/announce/ann-m094.pdf
Link for Hotel Reservations:
https://resweb.passkey.com/go/hitachiglobalstoragetech
Or Phone: 1-800-HRD-ROCK
Our group name is Hitachi Global Storage Technologies. Please
mention it when calling.
If you have any difficulty please let me know.
Best Regards,
Daniel J. Colegrove
Hitachi Global Storage Technologies
daniel.colegrove at hitachigst.com
(702) 614-6119
*
* 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  Thu Oct 15 18:32:10 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 16 Oct 2009 10:32:10 +0900
Subject: Posted: Latest version of the sata cabcon spec.
Message-ID: <mailman.680.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted the file on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Oct09/TPR_C102_V07.doc
Best regards,
Keiji Katata
PIONEER CORP.
"Leete, Brian A" <brian.a.leete at intel.com>@avc-pioneer.com on 2009/10/16
07:03:36
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  "mtfuji5 at avc-pioneer.com" <mtfuji5 at avc-pioneer.com>
cc:
$B7oL>(B:  [MtFuji] Latest version of the sata cabcon spec.
Mt Fuji team,
Here is the latest version of the SATA changes for Zero Power ODD that should
incorporate all changes discussed from the last meeting.
Let us know what you think by Tuesday morning US time. If there are no more
substantive changes to be included we$B!G(Bll start the review and approval
process
in the SATA cabcon group.
If there are more changes to be made, we can schedule another meeting to
address
them.
Wording changes/clarifications are always welcome.
Brian Leete
CO5-166
Intel Corporation
1365 NW Amberglen Parkway
Beaverton, Oregon, 97006
503-456-0484
 [TPR_C102_V07.doc]
*
* 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  Fri Oct 16 14:28:36 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Fri, 16 Oct 2009 16:28:36 -0500
Subject: possible incorrect LOWIR behavior description
Message-ID: <mailman.681.1441607350.22516.t10@sandbox.t10.org>

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

I am reading SBC-3 rev. 20, table 118 footnote a, a little more closely
today. It says:
"If the entry in the column is ???No???, or the LOWIR bit is set to zero in
the
Background Control mode page (see 6.4.3), then the device server shall not
create a Background Medium Scan parameter for the error. If the entry in
the column is ???Yes???, and the LOWIR bit is set to one in the Background
Control mode page, then the device server shall create a Background Medium
Scan parameter for the error."
It appears to me that the "yes" and "no" in this footnote should be
interchanged. The description of the LOWIR bit states that all entries
(either recovered or unrecovered) shall be placed in the log when LOWIR=0
but only log the unrecoverable errors when LOWIR=1.
The "yes" entries correspond to the unrecoverable error cases, the "no"
cases are the recovered error cases. I think the correct wordin for the
footnote should be:
"If the entry in the column is ???No???, or and the LOWIR bit is set to zero
one in the Background Control mode page (see 6.4.3), then the device server
shall not create a Background Medium Scan parameter for the error. If the
entry in the column is either "no" or ???Yes???, and the LOWIR bit is set to
one zero in the Background Control mode page, then the device server shall
create a Background Medium Scan parameter for the error."
If this footnote change isn't made, then the descriptions of the LOWIR bit
in the mode page do not match the footnote. Does anyone disagree with my
interpretation? I would like this item to be on the CAP agenda for the
November T10 meeting.


From Barry.Olawsky at hp.com  Sat Oct 17 11:18:43 2009
From: Barry.Olawsky at hp.com (Olawsky, Barry)
Date: Sat, 17 Oct 2009 18:18:43 +0000
Subject: SFF-8449, SFF-8636 Conference Call Minutes, October 8, 2009
Message-ID: <mailman.682.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Olawsky, Barry" <Barry.Olawsky at hp.com>
*
Minutes of SFF-8636, SFF-8449 conference call October 8, 2009
Attendance:
Mr. Greg McSorley		Amphenol
Mr. Jim McGrath 	Cinch
Mr. Mickey Felton		EMC
Mr. Elwood Parsons	Foxconn Electronics		    
Mr. Barry Olawsky		Hewlett Packard Co.
Mr. Harvey Newman		LSI Corp 
Mr. Brad Besmer 	LSI Corp.		      
Mr. Galen Fromm 	Molex Inc.			    
Mr. Michael Rost		Molex Inc.
Mr. Chris Fore		NetApp	      
Mr. Dan Smith		Seagate Technology		       
Mr. Benoit Mercier	STMicroelectonics
Mr. Scott Shuey 	TycoElectronics 		    
Mr. Toney Chew		Volex, Inc.			  
Mr. Atul Sharma 	Volex, Inc.
Mr. Michael Koffman	Western Digital Technology
16 in attendance
Agenda:
Discuss proposed content for SFF-8636 (Common Management Interface) and
SFF-8449 (Mini Multilane Series Management Interface). SFF-8436 (QSFP+ Copper
and Optical Transceiver) is to be used as a basis for SFF-8636.
Discussion:
Barry Olawsky (HP) shared a block diagram of the fixed/free side interface.
Comments from the previous conference call suggesting that the diagram
clearly indicate which portions of the fixed/free side interface are within
the scope of SFF-8636 were incorporated.
Barry proposed limiting the scope of SFF-8636 to the 2-wire management
interface protocol and memory map while excluding physical layer details of
the high-speed serial, management and power supply interfaces. Chris Fore
(NetApp) recommended inclusion of the timing diagrams. Barry agreed that
doing so was necessary. Chris also recommended the inclusion of text in 8636
to make the reader aware that physical layer details are included in
documents referencing 8636 (for example, SFF-8449). This would also explain
how SFF-8636 should be utilized.
The meeting adjourned at ~10:45AM CDT
Call schedule:
Upcoming conference calls: October 15 (past) and 22 2009
Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2.1 PHY WG 
Date: Thursday, October 15 (past), 22 2009 
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) 
Meeting Number: 826 515 680 
Meeting Password: newsas 
(Note: When logging onto WEBEX, please include your company following your
name. This will help the person recording attendance.)
*
* 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 Oct 17 23:01:01 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 18 Oct 2009 00:01:01 -0600
Subject: Recent T10 documents uploaded since 2009/10/11
Message-ID: <mailman.683.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SMC-3 Report Volume Information
(by: Curtis Ballard)
T10/08-215r7   Uploaded: 2009/10/16   157984 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-215r7.pdf
SMC-3 Use of element descriptor sense codes
(by: Noud Snelder)
T10/08-432r2   Uploaded: 2009/10/12   43558 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-432r2.pdf
SPL: Low Power Options for SAS phys
(by: George Penokie)
T10/09-063r5   Uploaded: 2009/10/13   822975 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-063r5.pdf
SMC3: Volume replication visibility, Rev 2
(by: Roger Cummings)
T10/09-308r2   Uploaded: 2009/10/13   207456 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-308r2.pdf
SSC-4: Append-only mode
(by: Kevin Butt)
T10/09-356r3   Uploaded: 2009/10/13   96034 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-356r3.pdf
SPL - Zone Persistence Fix
(by: Gregory Tabor)
T10/09-358r1   Uploaded: 2009/10/13   50578 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-358r1.pdf
Minutes SMC-3 14 October, 2009
(by: Kevin Butt)
T10/09-362r0   Uploaded: 2009/10/14   38555 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-362r0.pdf
SPC-4 XCOPY with no LIST IDENTIFIER
(by: Frederick Knight)
T10/09-363r0   Uploaded: 2009/10/15   126830 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-363r0.pdf
Working Drafts
--------------
SAS Protocol Layer (SPL)
(Editor: George Penokie)
 Rev: 04       Uploaded: 2009/10/14   8133431 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl-r04.pdf
(Report generated on 2009/10/18 at 00:01:01)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Mon Oct 19 11:06:13 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 19 Oct 2009 13:06:13 -0500
Subject: Comment on 09-063r5
Message-ID: <mailman.684.1441607350.22516.t10@sandbox.t10.org>

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

I have noted that the minutes of the Sept. Plenary meeting record that
09-063r4 was accepted for inclusion in SPL. Should the minutes actually
state "rev. 4 as ammended during the meeting" or perhaps say "rev. 5"? If
the minutes are actually correct (that rev. 4 was accepted) then what would


From George.Penokie at lsi.com  Tue Oct 20 14:49:51 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 20 Oct 2009 15:49:51 -0600
Subject: Comment on 09-063r5
Message-ID: <mailman.685.1441607350.22516.t10@sandbox.t10.org>

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

Gerry,
The minutes are correct. I recorded a lot of editorial comments during the
meeting but, at the meeting but I didn't request a new version of the
proposal be generated as the changes where ones that I would have made during
incorporation if I would have seen them. But I came to my senses when I
looked at again last week and decided to create a rev 5 that would be exactly
what I would put into SPL so as to not to bury any changes.
So that's why there is a rev 5.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Monday, October 19, 2009 1:06 PM
To: t10 at t10.org
Subject: Comment on 09-063r5
I have noted that the minutes of the Sept. Plenary meeting record that
09-063r4 was accepted for inclusion in SPL. Should the minutes actually state
"rev. 4 as ammended during the meeting" or perhaps say "rev. 5"? If the
minutes are actually correct (that rev. 4 was accepted) then what would be
the status of rev. 5?


From bmcferrin at dataplay.com  Tue Oct 20 15:41:49 2009
From: bmcferrin at dataplay.com (Bill McFerrin)
Date: Tue, 20 Oct 2009 16:41:49 -0600
Subject: MMC6rev2e has been uploaded to the t10 website
Message-ID: <mailman.686.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
MMC WG Members:
I have uploaded the revision of MMC6 that addresses many, many comments from
Mtfuji members.
The comments were very detailed and I appreciate the help. Processing the
comments took longer than I expected. In the case of document formatting
comments I made most of the changes. However, some were not done. I am
working now on addressing each comment for the rev 1 version of the comments
resolution document 09-283r0 where I will explain the cases where no change
was made.
For the commenters: Please verify that I have changed the document correctly.
Kind Regards,
Bill McFerrin
DPHI
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Barry.Olawsky at hp.com  Wed Oct 21 08:42:01 2009
From: Barry.Olawsky at hp.com (Olawsky, Barry)
Date: Wed, 21 Oct 2009 15:42:01 +0000
Subject: SFF-8449, SFF-8636 Conference Call Minutes, October 15, 2009
Message-ID: <mailman.687.1441607350.22516.t10@sandbox.t10.org>

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

Minutes of SFF-8636, SFF-8449 conference call October 15, 2009
Attendance:
Mr. Mickey Felton			    EMC
Mr. Elwood Parsons			  Foxconn Electronics
Mr. Barry Olawsky			    Hewlett Packard Co.
Mr. Gourgen Oganessyan		  Intersil
Mr. Tom Palkert 			      Luxtera
Mr. Kevin Witt					 Maxim Semiconductor
Mr. Michael Rost			      Molex Inc.
Mr. Chris Fore					 NetApp
Mr. Bob Clark					  NetApp
Mr. Mathieu Gagnon		       PMC-Sierra
Mr. Alvin Cox					  Seagate Technology
Mr. Peter Bauphman		       TycoElectronics
Mr. Matt Davis					Zarlink Semiconductor
?? in attendance
Agenda:
Discuss proposed content for SFF-8636 (Common Management Interface) and
SFF-8449 (Mini Multilane Series Management Interface). SFF-8436 (QSFP+ Copper
and Optical Transceiver) is to be used as a basis for SFF-8636.
Discussion:
Barry Olawsky (HP) shared a draft of the two-wire interface protocol portion
of SFF-8636. The first issue that was identified was a lack of a clear and
multi-purpose definition of reset. Since different referencing standards (of
SFF-8636) may utilize a combination of different reset mechanisms (protocol,
discrete hardware signal and as a last resort cycling the power to the free
side of the interface) all have to be clearly defined.
The next area of discussion was the addressing mechanism. The draft implied
an addressing scheme identical to what is available with most commercial
EEPROM devices (1010b nibble followed by a three bits that select 256 byte
blocks). It was quickly noted that such an addressing scheme was discussed in
prior standards using the two-wire interface for cable management and voted
down. Since the preference is to maintain compatibility with previous
implementations Barry agreed to modify the draft to only include the paging
mechanism for addressing memory above the first 128 bytes.
As the discussion of the timing tables continued, Tom Palkert (Luxtera)
pointed out that the modsel timing specification was missing. Barry noted
that the SFF-8636 draft was created from an SFF-8449 draft which did not
include modsel. Since SFF-8636 must support all legacy designs the draft will
need to be modified with the QSFP+ draft as a guideline.
The meeting adjourned at ~11:30AM CDT
Call schedule:
Upcoming conference calls: October 22 2009
Toll Free Dial in Number: (877)810-9442 International Access/Caller Paid Dial
In Number: (636)651-3190 PARTICIPANT CODE: 3243413
Webex information:
https://seagate.webex.com/seagate
Topic: SAS-2.1 PHY WG
Date: Thursday, October 22 2009
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) Meeting Number:
826 515 680 Meeting Password: newsas
(Note: When logging onto WEBEX, please include your company following your
name. This will help the person recording attendance.)


From bmcferrin at dataplay.com  Wed Oct 21 10:53:02 2009
From: bmcferrin at dataplay.com (Bill McFerrin)
Date: Wed, 21 Oct 2009 11:53:02 -0600
Subject: MMC6rev2e has been uploaded to the t10 website
Message-ID: <mailman.688.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
Dear Mr Tazawa,
Thank you for your comment.
Both MMC and Fuji are correct, but we have failed to describe clearly.
At loading time, the Drive must identify each layer and assign each layer a
number.
Once the layer numbering is assigned, Drive SHALL NOT change the layer
numbering until the disc is ejected.
Drive #1 may identify a 4 layer disc 0, 1, 2, 3 from the outer-most layer.
Drive #2 may identify the same disc as layers 0, 1, 2, 3 except number from
the inner-most layer.
This is OK.
Drive #1 must not change its layer numbering once it has made the numbering
decision.
Drive #2 must not change its layer numbering once it has made the numbering
decision.
I will create some descriptions in MMC6 to make this more clear.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Wed 21-Oct-09 1:08 AM
To: Bill McFerrin
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Dear Mr. McFerrin,
Thank you for uploading the latest revision of MMC6.
> For the commenters: Please verify that I have changed the document
correctly.
I have confirmed that pointed parts are changed correctly.
Recently, we noticed another mis-description to be revised.
It is regarding the "Hybrid Disc."
[1]:
In "4.25.3 Format-layer selection mechanism using the START STOP UNIT
command,"
there is a below sentence on page 192 (PDF-page240):
  "Format-layers are numbered from zero and incremented by one.
   The assignment rule of numbers to Formatlayers is vendor-specific."
[2]:
On the other hand,
In "6.22.3.1.8 Format Code 90h: List of recognized format layers,"
there is a below sentence on page 399 (PDF-page447):
  "The numbering of the Format-layer shall be in numerical ascending order
   of the Format-layer type code defined in Table 393."
These 2 sentences does not match each other.
The same conflict can be seen in Mt. Fuji 1.20 (September version).
According to Katata-san and Ai-san, [2] is correct while [1] is not.
   ftp.avc-pioneer.com/Mtfuji_6/Minutes/MinNov05.pdf
Due to above meeting minutes (2005.11),
editor forgot to revise [1] when [2] was newly clarified and added.
Ai-san will notify this issue through Fuji-reflector shortly,
and Katata-san will revise the [1] to match with [2].
So MMC6 would be.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Bill McFerrin
Sent: Wednesday, October 21, 2009 7:42 AM
To: t10 at t10.org
Subject: MMC6rev2e has been uploaded to the t10 website
* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
MMC WG Members:
I have uploaded the revision of MMC6 that addresses many, many comments from
Mtfuji members.
The comments were very detailed and I appreciate the help. Processing the
comments took longer than I expected. In the case of document formatting
comments I made most of the changes. However, some were not done. I am
working now on addressing each comment for the rev 1 version of the comments
resolution document 09-283r0 where I will explain the cases where no change
was made.
For the commenters: Please verify that I have changed the document correctly.
Kind Regards,
Bill McFerrin
DPHI
*
* 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 bmcferrin at dataplay.com  Wed Oct 21 11:14:02 2009
From: bmcferrin at dataplay.com (Bill McFerrin)
Date: Wed, 21 Oct 2009 12:14:02 -0600
Subject: MMC6rev2e has been uploaded to the t10 website
Message-ID: <mailman.689.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
Hi,
I see another problem in 6.22.3.1.8. I may have misunderstood the real
meaning of your comment.
MMC6r2d Table 385 shows the layers being reported according to layer number
(which may be assigned by the drive).
The text above table 386 suggests that layer reporting is ordered by layer
type code.
Ordering by type code provides no value. I prefer to remove ordering by type
code.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Wed 21-Oct-09 1:08 AM
To: Bill McFerrin
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Dear Mr. McFerrin,
Thank you for uploading the latest revision of MMC6.
> For the commenters: Please verify that I have changed the document
correctly.
I have confirmed that pointed parts are changed correctly.
Recently, we noticed another mis-description to be revised.
It is regarding the "Hybrid Disc."
[1]:
In "4.25.3 Format-layer selection mechanism using the START STOP UNIT
command,"
there is a below sentence on page 192 (PDF-page240):
  "Format-layers are numbered from zero and incremented by one.
   The assignment rule of numbers to Formatlayers is vendor-specific."
[2]:
On the other hand,
In "6.22.3.1.8 Format Code 90h: List of recognized format layers,"
there is a below sentence on page 399 (PDF-page447):
  "The numbering of the Format-layer shall be in numerical ascending order
   of the Format-layer type code defined in Table 393."
These 2 sentences does not match each other.
The same conflict can be seen in Mt. Fuji 1.20 (September version).
According to Katata-san and Ai-san, [2] is correct while [1] is not.
   ftp.avc-pioneer.com/Mtfuji_6/Minutes/MinNov05.pdf
Due to above meeting minutes (2005.11),
editor forgot to revise [1] when [2] was newly clarified and added.
Ai-san will notify this issue through Fuji-reflector shortly,
and Katata-san will revise the [1] to match with [2].
So MMC6 would be.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Bill McFerrin
Sent: Wednesday, October 21, 2009 7:42 AM
To: t10 at t10.org
Subject: MMC6rev2e has been uploaded to the t10 website
* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
MMC WG Members:
I have uploaded the revision of MMC6 that addresses many, many comments from
Mtfuji members.
The comments were very detailed and I appreciate the help. Processing the
comments took longer than I expected. In the case of document formatting
comments I made most of the changes. However, some were not done. I am
working now on addressing each comment for the rev 1 version of the comments
resolution document 09-283r0 where I will explain the cases where no change
was made.
For the commenters: Please verify that I have changed the document correctly.
Kind Regards,
Bill McFerrin
DPHI
*
* 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 eijirou-tazawa at hlds.co.jp  Wed Oct 21 17:31:54 2009
From: eijirou-tazawa at hlds.co.jp (=?iso-2022-jp?B?RWlqaXJvIFRhemF3YSgbJEJFRF83MVFGc086GyhCKQ==?=)
Date: Thu, 22 Oct 2009 09:31:54 +0900
Subject: MMC6rev2e has been uploaded to the t10 website
Message-ID: <mailman.690.1441607350.22516.t10@sandbox.t10.org>

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

Dear Mr. McFerrin,
Thank you for answering, but I am confusing about your comment.
According to the meeting minutes "Minutes, Mt. Fuji November 8 Morning, 2005,
Austin TX," it is likely that layer reporting is ordered by layer type code.
Please refer to the attached minutes, "[Q1] What is the order of listed
Format Layer by RDS command?," on page 2.
It would be appreciated if you could clarify this matter.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: Bill McFerrin [mailto:bmcferrin at dataplay.com] 
Sent: Thursday, October 22, 2009 3:14 AM
To: Eijiro Tazawa($BED_71QFsO:(J)
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Hi,
I see another problem in 6.22.3.1.8. I may have misunderstood the real
meaning of your comment.
MMC6r2d Table 385 shows the layers being reported according to layer number
(which may be assigned by the drive).
The text above table 386 suggests that layer reporting is ordered by layer
type code.
Ordering by type code provides no value. I prefer to remove ordering by type
code.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Wed 21-Oct-09 1:08 AM
To: Bill McFerrin
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Dear Mr. McFerrin,
Thank you for uploading the latest revision of MMC6.
> For the commenters: Please verify that I have changed the document
correctly.
I have confirmed that pointed parts are changed correctly.
Recently, we noticed another mis-description to be revised.
It is regarding the "Hybrid Disc."
[1]:
In "4.25.3 Format-layer selection mechanism using the START STOP UNIT
command,"
there is a below sentence on page 192 (PDF-page240):
  "Format-layers are numbered from zero and incremented by one.
   The assignment rule of numbers to Formatlayers is vendor-specific."
[2]:
On the other hand,
In "6.22.3.1.8 Format Code 90h: List of recognized format layers,"
there is a below sentence on page 399 (PDF-page447):
  "The numbering of the Format-layer shall be in numerical ascending order
   of the Format-layer type code defined in Table 393."
These 2 sentences does not match each other.
The same conflict can be seen in Mt. Fuji 1.20 (September version).
According to Katata-san and Ai-san, [2] is correct while [1] is not.
   ftp.avc-pioneer.com/Mtfuji_6/Minutes/MinNov05.pdf
Due to above meeting minutes (2005.11),
editor forgot to revise [1] when [2] was newly clarified and added.
Ai-san will notify this issue through Fuji-reflector shortly, and Katata-san
will revise the [1] to match with [2].
So MMC6 would be.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Bill McFerrin
Sent: Wednesday, October 21, 2009 7:42 AM
To: t10 at t10.org
Subject: MMC6rev2e has been uploaded to the t10 website
* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
MMC WG Members:
I have uploaded the revision of MMC6 that addresses many, many comments from
Mtfuji members.
The comments were very detailed and I appreciate the help. Processing the
comments took longer than I expected. In the case of document formatting
comments I made most of the changes. However, some were not done. I am
working now on addressing each comment for the rev 1 version of the comments
resolution document 09-283r0 where I will explain the cases where no change
was made.
For the commenters: Please verify that I have changed the document correctly.
Kind Regards,
Bill McFerrin
DPHI
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From ai.takaharu at jp.panasonic.com  Wed Oct 21 17:34:30 2009
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Thu, 22 Oct 2009 09:34:30 +0900
Subject: Hybrid disc related issue
Message-ID: <mailman.691.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Mt.Fuji people,
We, editors group, have received a comment which ponted out the Hybrid
disc model section was in contradiction with the command for that
function.
In the model section, the assignement rule of Format-layer number for
each Format-layer was defined as vendor-sepcific. But in READ DISC
STRUCTURE command with Format 90h, Format-layer must be numbered in
numerical ascending order of the Format-layer type code.
We have reviewed the meeting minutes of November 2005 Mt.Fuji meeting
and we realized that the definition in the model section had not been
revised according to the discussion result.
So, we would like to propose to correct the text in 6.3 in the Hybrid
disc model section as follows.
Current:
    Format-layers are numbered from zero and incremented by one. The
    assignment rule of numbers to Format-layers is vendor-specific.
Proposed:
    Format-layers are numbered from zero and incremented by one. The
    numbering of the Format-layer shall be in numerical ascending order
    of the Format-layer type code defined in Table 639.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Mignon.M.Fernandez at bitmicro.com  Wed Oct 21 23:31:00 2009
From: Mignon.M.Fernandez at bitmicro.com (Mignon Fernandez)
Date: Thu, 22 Oct 2009 14:31:00 +0800
Subject: question re: Training SNW
Message-ID: <mailman.692.1441607350.22516.t10@sandbox.t10.org>

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

Hello,
We would like to clarify some points regarding the Training SNW.
>From page 301 of T10/1760-D Revision 16 specs:
6.8.4.12.5 Transition SP29:SAS_Train to SP30:SAS_TrainingDone
This transition shall occur if:
a) the TLT timer has not expired;
b) this state receives a Training Completed message;
c) dword synchronization is acquired; and
d) this state receives a TRAIN Received message or a TRAIN_DONE Received
message.
If a TRAIN_DONE Received message was received, then the transition shall
include a TRAIN_DONE
Received argument.
Question #1:
What conditions should be met before the SP_SM receiver sends a Training
Completed message?
Does Training Completed mean that a TRAIN_PATTERN has been received and
transmitted?
Question #2:
What happens if this scenario occurs?
? While the phy is transmitting a TRAIN_PATTERN, the receiver detects a
TRAIN_DONE pattern.
(no TRAIN_PATTERN is ever received from the attached phy). Is it OK to
transition to SAS_TrainingDone?
Or does the phy really have to wait for a TRAIN_PATTERN.
Thank you
------------------------------------------------------------
CONFIDENTIALITY NOTICE 
This email and any attached documents may be confidential
and property of BiTMICRO Networks, Inc. If you are not the 
intended recipient, you may not disclose, copy, distribute,
or act in reliance on the information in this email.
Also note, this email and attached documents are scanned for 
the presence of virus.	Changes made to this email after it 


From Frederick.Knight at netapp.com  Thu Oct 22 07:43:10 2009
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Thu, 22 Oct 2009 10:43:10 -0400
Subject: T10 review of SNIA HSI whitepaper
Message-ID: <mailman.693.1441607350.22516.t10@sandbox.t10.org>

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

As discussed at the September T10 meeting in Boston, the SNIA HSI TWG
has been working on a document that describes several SPC/SBC commands
(specifically XCOPY, UNMAP, and WRITE SAME (with UNMAP).
The SNIA HSI TWG has requested that T10 be solicited to provide comments
and feedback on the whitepaper.  Note, that this whitepaper is more of
an introduction/overview to these operations, describing some common use
cases, and how these commands might be used to satisfy the requirements
of those use cases; and refers to the actual T10 standard for the
technical details.
Document 09-375 has been posted which contains this request, and a
pointer to the SNIA document.
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-375r0.pdf
or, the SNIA document can be accessed directly at:
http://www.snia.org/publicreview/
		Fred Knight


From bmcferrin at dataplay.com  Thu Oct 22 07:47:05 2009
From: bmcferrin at dataplay.com (Bill McFerrin)
Date: Thu, 22 Oct 2009 08:47:05 -0600
Subject: MMC6rev2e has been uploaded to the t10 website
Message-ID: <mailman.694.1441607350.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
Hi,
We should select one of the two requirements so that all drives that are
already implementing hybrid disc can be compliant.
If a drive is compliant with 6.22.3.1.8, then it is also compliant with the
specification in 4.25.
The reverse may not be true.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Wed 21-Oct-09 7:31 PM
To: Bill McFerrin
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Dear Mr. McFerrin,
Thank you for answering, but I am confusing about your comment.
According to the meeting minutes "Minutes, Mt. Fuji November 8 Morning, 2005,
Austin TX," it is likely that layer reporting is ordered by layer type code.
Please refer to the attached minutes, "[Q1] What is the order of listed
Format Layer by RDS command?," on page 2.
It would be appreciated if you could clarify this matter.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: Bill McFerrin [mailto:bmcferrin at dataplay.com] 
Sent: Thursday, October 22, 2009 3:14 AM
To: Eijiro Tazawa(?????)
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Hi,
I see another problem in 6.22.3.1.8. I may have misunderstood the real
meaning of your comment.
MMC6r2d Table 385 shows the layers being reported according to layer number
(which may be assigned by the drive).
The text above table 386 suggests that layer reporting is ordered by layer
type code.
Ordering by type code provides no value. I prefer to remove ordering by type
code.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Wed 21-Oct-09 1:08 AM
To: Bill McFerrin
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Dear Mr. McFerrin,
Thank you for uploading the latest revision of MMC6.
> For the commenters: Please verify that I have changed the document
correctly.
I have confirmed that pointed parts are changed correctly.
Recently, we noticed another mis-description to be revised.
It is regarding the "Hybrid Disc."
[1]:
In "4.25.3 Format-layer selection mechanism using the START STOP UNIT
command,"
there is a below sentence on page 192 (PDF-page240):
  "Format-layers are numbered from zero and incremented by one.
   The assignment rule of numbers to Formatlayers is vendor-specific."
[2]:
On the other hand,
In "6.22.3.1.8 Format Code 90h: List of recognized format layers,"
there is a below sentence on page 399 (PDF-page447):
  "The numbering of the Format-layer shall be in numerical ascending order
   of the Format-layer type code defined in Table 393."
These 2 sentences does not match each other.
The same conflict can be seen in Mt. Fuji 1.20 (September version).
According to Katata-san and Ai-san, [2] is correct while [1] is not.
   ftp.avc-pioneer.com/Mtfuji_6/Minutes/MinNov05.pdf
Due to above meeting minutes (2005.11),
editor forgot to revise [1] when [2] was newly clarified and added.
Ai-san will notify this issue through Fuji-reflector shortly, and Katata-san
will revise the [1] to match with [2].
So MMC6 would be.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Bill McFerrin
Sent: Wednesday, October 21, 2009 7:42 AM
To: t10 at t10.org
Subject: MMC6rev2e has been uploaded to the t10 website
* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
MMC WG Members:
I have uploaded the revision of MMC6 that addresses many, many comments from
Mtfuji members.
The comments were very detailed and I appreciate the help. Processing the
comments took longer than I expected. In the case of document formatting
comments I made most of the changes. However, some were not done. I am
working now on addressing each comment for the rev 1 version of the comments
resolution document 09-283r0 where I will explain the cases where no change
was made.
For the commenters: Please verify that I have changed the document correctly.
Kind Regards,
Bill McFerrin
DPHI
*
* 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 Black_David at emc.com  Thu Oct 22 13:56:34 2009
From: Black_David at emc.com (Black_David at emc.com)
Date: Thu, 22 Oct 2009 16:56:34 -0400
Subject: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
Message-ID: <mailman.695.1441607350.22516.t10@sandbox.t10.org>

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

I just uploaded a clarification proposal for this as 09-370r0.
The proposal's much shorter than this email discussion ...
Thanks,
--David
________________________________
	From: Black, David 
	Sent: Tuesday, October 13, 2009 8:22 PM
	To: Kevin D Butt; Tim Johnson; David L Swanson; Lou Dickens
	Cc: t10 at t10.org; Black, David
	Subject: RE: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
	Kevin,
	To be precise, what's actually exchanged is key exchange
material.  Whether
	that material is actually a public key is a potential matter of
hair-splitting,
	as *if* one wants to view it as a member of a key pair, that key
pair is
	usually ephemeral and in particular, the key is not associated
with any identity
	(e.g., the key exchange material is not being used to establish
authentication).
	FWIW, the security community does not generally view an
ephemeral DH exchange
	(at least the mod-P variety) as involving key pairs.
	I think I just "won" an action to write a proposal for November
that:
	- Changes "format" to "binary representation" in the crucial
location.
	- Corrects the ECP key binary representation mistake in RFC
4753.
	- Makes the vague reference to "registry" more precise (at the
very least
	    a Table number and column header are called for).
	I'm unlikely to use the phrase "public key" in that proposal
;-).
	Thanks,
	--David
________________________________
		From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
		Sent: Tuesday, October 13, 2009 7:31 PM
		To: Black, David; Tim Johnson; David L Swanson; Lou
Dickens
		Cc: t10 at t10.org
		Subject: RE: KEY EXCHANGE DATA and confusion in SPC-4
IKEv2-SCSI
		David, 
		Thank you for your reply.  If I read what you said
correctly, then the value for the ECP group would also be the public
key.  But I think I am missing something because that doesn't make sense
that they are both the same thing and we don't state that straight out
in SPC-4. 
		As for the wording change, changing "format" to "binary
representation" makes the text read 
		>>> 
		The KEY EXCHANGE DATA field contains the sender's
Diffie-Hellman public value for this key exchange. The <binary
representation> of key exchange data is as specified in the reference
cited in that registry for the value used." 
		>>>> 
		This still leaves me hanging on what "the reference
cited in that registry for the value used" is referring to. 
		This sounds like a double or triple indirection and it
is not very clear. 
		Thanks, 
		Kevin D. Butt
		SCSI & Fibre Channel Architect, Tape Firmware
		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/
<http://www-03.ibm.com/servers/storage/&gt;  
From:	<Black_David at emc.com> 
To:	Kevin D Butt/Tucson/IBM at IBMUS, <t10 at t10.org> 
Date:	10/13/2009 04:10 PM 
Subject:	RE: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI 
________________________________
		Kevin, 
		> The question of the format is to be used is not clear
since it is not clear what the reference cited is.
		> This still bugs me. If this field is simply the public
key (with prepended zeros to pad to the length of
		> the prime modulus (if that function was chosen), why
not just say that. 
		For a mod-P group, that's exactly what it is.  For ECP,
the answer is a
		more complex form of "yes" because the representation
turns out to be
		partially implicit. 
		> Now in http://tools.ietf.org/html/rfc4753
<http://tools.ietf.org/html/rfc4753&gt;  there is a mention of using a KE
format for ECP group generated
		> public key in section 7. In the section which follows
there are some examples. 
		Unfortunately, RFC 4753 got it wrong - there's a very
important erratum that
		invalidates all of its examples - only the x value is
passed, not both the
		x and y values, see: 
		http://www.rfc-editor.org/errata_search.php?rfc=4753
<http://www.rfc-editor.org/errata_search.php?rfc=4753&gt;	
		We will need to fix this in SPC-4. 
		> In these examples there are 2 DWORDs preceding the
public key.  The first is the number of bytes
		> of the payload. The second is the group number in the
upper half of the DWORD. 
		Not exactly - those examples are complete IKE KEi and
KEr payloads, so
		they contain the entire payload headers, with the NEXT
PAYLOAD field
		set to zero in each case for the purpose of the example.
For IKEv2-SCSI,
		these payload headers are specified as bytes 0-7 in
table 427 (SPC-4 rev 21). 
		> So, does the format then depend on which D-H group is
being used? 
		Yes and no:
		- Yes, you have to know whether it's a mod P group vs.
an ECP group in
		   order to figure out what to do with the key exchange
material.
		   Trying to use a mod-P DH value as an ECP x coordinate
or vice-versa
		   is not going to work very well :-).
		- No, the payload format is common; headers plus key
exchange material. 
		> Just the public key if it's a mod P group, and the
public key preceded by these two DWORDs if it's an ECP group? 
		No, it's always the "public key".  The two DWORDS are
payload headers
		that are already specified in SPC-4 Table 427. 
		> My questions are: 
		> 1) Is the answer, Just the public key if it's a mod P
group?
		Yes. 
		> 2) What can be done in SPC-4 to clear up the
confusion?  Can this be more detailed or can there be an example added?
		At the very least, we need to fix the mistake in RFC
4753.  If we changed
		"format" to "binary representation" would that help? 
		Thanks,
		--David 
________________________________
		From: owner-t10 at t10.org [mailto:owner-t10 at t10.org
<mailto:owner-t10 at t10.org> ] On Behalf Of Kevin D Butt
		Sent: Tuesday, October 13, 2009 12:45 PM
		To: t10 at t10.org
		Subject: KEY EXCHANGE DATA and confusion in SPC-4
IKEv2-SCSI
		T10 Security experts, 
		I am receiving requests to clarify what is intended for
the key exchange data field in the key exchange payload for the D-H
portion of IKEv2-SCSI.	I must admit I cannot figure it out.  We always
get wrapped around the wording, " The format of key exchange data is as
specified in the reference cited in that registry for the value used"
What is the reference cited and what is the registry?  Then, since the
term format is used, it leads one to believe there is something more
than just a public key. 
		Here is a note I received that highlights the confusion:
		Is the key data field of the .key exchange payload is
simply the public key from the agreed upon D-H group? What makes this
confusing is the SPC-4 standard in section 7.6.3.5.3 Key Exchange
Payload which states 
		The KEY EXCHANGE DATA field contains the sender's
Diffie-Hellman public value for this key exchange. The format of 
		key exchange data is as specified in the reference cited
in that registry for the value used. 
		The question of the format is to be used is not clear
since it is not clear what the reference cited is.This still bugs me. If
this field is simply the public key (with prepended zeros to pad to the
length of the prime modulus (if that function was chosen), why not just
say that. Mentioning a format makes it sound like there is more to it.
Now in http://tools.ietf.org/html/rfc4753
<http://tools.ietf.org/html/rfc4753&gt;  there is a mention of using a KE
format for ECP group generated public key in section 7. In the section
which follows there are some examples. In these examples there are 2
DWORDs preceding the public key. The first is the number of bytes of the
payload. The second is the group number in the upper half of the DWORD.
In http://tools.ietf.org/html/rfc2408
<http://tools.ietf.org/html/rfc2408&gt; , the Internet Security Association
and Key Management Protocol (ISAKMP), section 3.7 defines the key
exchange payload which includes a Key Exchange Data field. Again, it
seems this field depends on the D-H group. although this (ISAKMP)
standard is more general. 
		So, does the format then depend on which D-H group is
being used? Just the public key if it's a mod P group, and the public
key preceded by these two DWORDs if it's an ECP group? 
		My questions are: 
		1) Is the answer, Just the public key if it's a mod P
group? 
		2) What can be done in SPC-4 to clear up the confusion?
Can this be more detailed or can there be an example added? 
		thanks, 
		Kevin D. Butt
		SCSI & Fibre Channel Architect, Tape Firmware
		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/
<http://www-03.ibm.com/servers/storage/&gt;  


From lohmeyer at t10.org  Sat Oct 24 23:00:45 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 25 Oct 2009 00:00:45 -0600
Subject: Recent T10 documents uploaded since 2009/10/18
Message-ID: <mailman.696.1441607351.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPL - STP extended buffer support
(by: Tim Symons)
T10/09-268r4   Uploaded: 2009/10/20   130681 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-268r4.pdf
Results of Letter Ballot on forwarding SAS-2.1 to first public review
(by: John Lohmeyer)
T10/09-353r0   Uploaded: 2009/10/20   349034 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-353r0.pdf
Results of Letter Ballot on forwarding SAS-2.1 to first public review
(by: John Lohmeyer)
T10/09-353r0   Uploaded: 2009/10/20   95938 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-353r0.txt
SBC-3 Incorrect description of LOWIR bit effect in table 118
(by: Gerald Houlder)
T10/09-365r0   Uploaded: 2009/10/19   127123 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-365r0.pdf
T11 Liaison Report, October 2009
(by: Steven Wilson)
T10/09-368r0   Uploaded: 2009/10/20   24700 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-368r0.pdf
SPC-4 - no UA on RELEASE
(by: Frederick Knight)
T10/09-369r0   Uploaded: 2009/10/21   158299 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-369r0.pdf
SPC-4: IKEv2-SCSI Key Exchange Clarification
(by: David Black)
T10/09-370r0   Uploaded: 2009/10/22   28807 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-370r0.pdf
SAS 3 Channel Analysis
(by: Bill Lye)
T10/09-371r0   Uploaded: 2009/10/23   299476 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-371r0.pdf
SBC-3: Verify CDB - Unrecovered Read Error
(by: George Penokie)
T10/09-372r0   Uploaded: 2009/10/21   66630 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-372r0.pdf
Help for those who cannot find initiator/target ports in SAM-5
(by: Ralph Weber)
T10/09-373r0   Uploaded: 2009/10/21   23839 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-373r0.pdf
SPL: Miscellaneous Fixes
(by: George Penokie)
T10/09-374r0   Uploaded: 2009/10/22   69844 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-374r0.pdf
SNIA XCOPY/UNMAP whte paper
(by: Frederick Knight)
T10/09-375r0   Uploaded: 2009/10/22   33604 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-375r0.pdf
Crosstalk in Copper Cables - Data Plots
(by: Jim McGrath)
T10/09-376r0   Uploaded: 2009/10/23   1311885 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-376r0.pdf
Working Drafts
--------------
MultiMedia Command Set - 6 (MMC-6)
(Editor: Bill McFerrin)
 Rev: 02e      Uploaded: 2009/10/20   4580082 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc6r02e.pdf
(Report generated on 2009/10/25 at 00:00:45)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From eijirou-tazawa at hlds.co.jp  Sun Oct 25 23:37:30 2009
From: eijirou-tazawa at hlds.co.jp (=?iso-2022-jp?B?RWlqaXJvIFRhemF3YSgbJEJFRF83MVFGc086GyhCKQ==?=)
Date: Mon, 26 Oct 2009 15:37:30 +0900
Subject: MMC6rev2e has been uploaded to the t10 website
Message-ID: <mailman.697.1441607351.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* =?iso-2022-jp?B?RWlqaXJvIFRhemF3YSgbJEJFRF83MVFGc086GyhCKQ==?=
<eijirou-tazawa at hlds.co.jp>
*
Hello,
I think the meeting minutes (on November 8, 2005 at Austin TX) says the
requirement of 6.22.3.1.8 had been selected already.
Is my understanding correct?
Best regards,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: Bill McFerrin [mailto:bmcferrin at dataplay.com] 
Sent: Thursday, October 22, 2009 11:47 PM
To: Eijiro Tazawa($BED_71QFsO:(J)
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Hi,
We should select one of the two requirements so that all drives that are
already implementing hybrid disc can be compliant.
If a drive is compliant with 6.22.3.1.8, then it is also compliant with the
specification in 4.25.
The reverse may not be true.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Wed 21-Oct-09 7:31 PM
To: Bill McFerrin
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Dear Mr. McFerrin,
Thank you for answering, but I am confusing about your comment.
According to the meeting minutes "Minutes, Mt. Fuji November 8 Morning, 2005,
Austin TX," it is likely that layer reporting is ordered by layer type code.
Please refer to the attached minutes, "[Q1] What is the order of listed
Format Layer by RDS command?," on page 2.
It would be appreciated if you could clarify this matter.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: Bill McFerrin [mailto:bmcferrin at dataplay.com] 
Sent: Thursday, October 22, 2009 3:14 AM
To: Eijiro Tazawa(?????)
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Hi,
I see another problem in 6.22.3.1.8. I may have misunderstood the real
meaning of your comment.
MMC6r2d Table 385 shows the layers being reported according to layer number
(which may be assigned by the drive).
The text above table 386 suggests that layer reporting is ordered by layer
type code.
Ordering by type code provides no value. I prefer to remove ordering by type
code.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Wed 21-Oct-09 1:08 AM
To: Bill McFerrin
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Dear Mr. McFerrin,
Thank you for uploading the latest revision of MMC6.
> For the commenters: Please verify that I have changed the document
correctly.
I have confirmed that pointed parts are changed correctly.
Recently, we noticed another mis-description to be revised.
It is regarding the "Hybrid Disc."
[1]:
In "4.25.3 Format-layer selection mechanism using the START STOP UNIT
command,"
there is a below sentence on page 192 (PDF-page240):
  "Format-layers are numbered from zero and incremented by one.
   The assignment rule of numbers to Formatlayers is vendor-specific."
[2]:
On the other hand,
In "6.22.3.1.8 Format Code 90h: List of recognized format layers,"
there is a below sentence on page 399 (PDF-page447):
  "The numbering of the Format-layer shall be in numerical ascending order
   of the Format-layer type code defined in Table 393."
These 2 sentences does not match each other.
The same conflict can be seen in Mt. Fuji 1.20 (September version).
According to Katata-san and Ai-san, [2] is correct while [1] is not.
   ftp.avc-pioneer.com/Mtfuji_6/Minutes/MinNov05.pdf
Due to above meeting minutes (2005.11),
editor forgot to revise [1] when [2] was newly clarified and added.
Ai-san will notify this issue through Fuji-reflector shortly, and Katata-san
will revise the [1] to match with [2].
So MMC6 would be.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Bill McFerrin
Sent: Wednesday, October 21, 2009 7:42 AM
To: t10 at t10.org
Subject: MMC6rev2e has been uploaded to the t10 website
* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
MMC WG Members:
I have uploaded the revision of MMC6 that addresses many, many comments from
Mtfuji members.
The comments were very detailed and I appreciate the help. Processing the
comments took longer than I expected. In the case of document formatting
comments I made most of the changes. However, some were not done. I am
working now on addressing each comment for the rev 1 version of the comments
resolution document 09-283r0 where I will explain the cases where no change
was made.
For the commenters: Please verify that I have changed the document correctly.
Kind Regards,
Bill McFerrin
DPHI
*
* 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 bmcferrin at dataplay.com  Mon Oct 26 07:25:47 2009
From: bmcferrin at dataplay.com (Bill McFerrin)
Date: Mon, 26 Oct 2009 08:25:47 -0600
Subject: MMC6rev2e has been uploaded to the t10 website
Message-ID: <mailman.698.1441607351.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
Hi,
That appears to be correct. I shall start with that assumption in 2f.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Mon 26-Oct-09 1:37 AM
To: Bill McFerrin
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Hello,
I think the meeting minutes (on November 8, 2005 at Austin TX) says the
requirement of 6.22.3.1.8 had been selected already.
Is my understanding correct?
Best regards,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: Bill McFerrin [mailto:bmcferrin at dataplay.com] 
Sent: Thursday, October 22, 2009 11:47 PM
To: Eijiro Tazawa(?????)
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Hi,
We should select one of the two requirements so that all drives that are
already implementing hybrid disc can be compliant.
If a drive is compliant with 6.22.3.1.8, then it is also compliant with the
specification in 4.25.
The reverse may not be true.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Wed 21-Oct-09 7:31 PM
To: Bill McFerrin
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Dear Mr. McFerrin,
Thank you for answering, but I am confusing about your comment.
According to the meeting minutes "Minutes, Mt. Fuji November 8 Morning, 2005,
Austin TX," it is likely that layer reporting is ordered by layer type code.
Please refer to the attached minutes, "[Q1] What is the order of listed
Format Layer by RDS command?," on page 2.
It would be appreciated if you could clarify this matter.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: Bill McFerrin [mailto:bmcferrin at dataplay.com] 
Sent: Thursday, October 22, 2009 3:14 AM
To: Eijiro Tazawa(?????)
Cc: t10 at t10.org
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Hi,
I see another problem in 6.22.3.1.8. I may have misunderstood the real
meaning of your comment.
MMC6r2d Table 385 shows the layers being reported according to layer number
(which may be assigned by the drive).
The text above table 386 suggests that layer reporting is ordered by layer
type code.
Ordering by type code provides no value. I prefer to remove ordering by type
code.
Kind Regards,
Bill McFerrin
DPHI
-----Original Message-----
From: Eijiro Tazawa(?????) [mailto:eijirou-tazawa at hlds.co.jp]
Sent: Wed 21-Oct-09 1:08 AM
To: Bill McFerrin
Subject: RE: MMC6rev2e has been uploaded to the t10 website
Dear Mr. McFerrin,
Thank you for uploading the latest revision of MMC6.
> For the commenters: Please verify that I have changed the document
correctly.
I have confirmed that pointed parts are changed correctly.
Recently, we noticed another mis-description to be revised.
It is regarding the "Hybrid Disc."
[1]:
In "4.25.3 Format-layer selection mechanism using the START STOP UNIT
command,"
there is a below sentence on page 192 (PDF-page240):
  "Format-layers are numbered from zero and incremented by one.
   The assignment rule of numbers to Formatlayers is vendor-specific."
[2]:
On the other hand,
In "6.22.3.1.8 Format Code 90h: List of recognized format layers,"
there is a below sentence on page 399 (PDF-page447):
  "The numbering of the Format-layer shall be in numerical ascending order
   of the Format-layer type code defined in Table 393."
These 2 sentences does not match each other.
The same conflict can be seen in Mt. Fuji 1.20 (September version).
According to Katata-san and Ai-san, [2] is correct while [1] is not.
   ftp.avc-pioneer.com/Mtfuji_6/Minutes/MinNov05.pdf
Due to above meeting minutes (2005.11),
editor forgot to revise [1] when [2] was newly clarified and added.
Ai-san will notify this issue through Fuji-reflector shortly, and Katata-san
will revise the [1] to match with [2].
So MMC6 would be.
Sincerely yours,
Eijiro Tazawa
Hitachi-LG Data Storage, Inc.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Bill McFerrin
Sent: Wednesday, October 21, 2009 7:42 AM
To: t10 at t10.org
Subject: MMC6rev2e has been uploaded to the t10 website
* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill McFerrin" <bmcferrin at dataplay.com>
*
MMC WG Members:
I have uploaded the revision of MMC6 that addresses many, many comments from
Mtfuji members.
The comments were very detailed and I appreciate the help. Processing the
comments took longer than I expected. In the case of document formatting
comments I made most of the changes. However, some were not done. I am
working now on addressing each comment for the rev 1 version of the comments
resolution document 09-283r0 where I will explain the cases where no change
was made.
For the commenters: Please verify that I have changed the document correctly.
Kind Regards,
Bill McFerrin
DPHI
*
* 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 gedlund at us.ibm.com  Mon Oct 26 12:39:26 2009
From: gedlund at us.ibm.com (Gregory R Edlund)
Date: Mon, 26 Oct 2009 14:39:26 -0500
Subject: In Search of SAS Board Design Guide
Message-ID: <mailman.699.1441607351.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gregory R Edlund <gedlund at us.ibm.com>
*
Is anyone on the reflector aware of a SAS board design guide similar to the
one Intel wrote for PCI Express, i.e. recommended line widths and spacings,
max length, etc?
Please respond to gedlund at us.ibm.com
Many thanks.
Greg Edlund
Senior Engineer
Signal Integrity and System Timing
IBM Systems & Technology Group
3605 Hwy. 52 N	Bldg 050-2
Rochester, MN 55901
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Mon Oct 26 18:30:59 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 26 Oct 2009 18:30:59 -0700
Subject: SSC-4: Volume specific MAM attribute proposals (09-366 & 09-367)
Message-ID: <mailman.700.1441607351.22516.t10@sandbox.t10.org>

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

I have uploaded two proposals related to MAM parameters. I hope to be able 
to at least discuss these in Las Vegas and get a good feel for the 
direction the group will take these.
The first, 09-366r0 is for a Volume Write Juncture which maintains a type 
of write pass of a volume.
The second, 09-367r0 is for a Volume Coherency Information which may be 
used to maintain coherency of a volume across partitions and mounts.
The Volume Coherency Information attribute uses the Volume Write Juncture 
attribute.  The Volume Write Juncture attribute is useful even if the 
Volume Coherency Information attribute does not exist.
2009/10/26 15:39:13 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-366r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
=======================================================================
2009/10/26 19:03:13 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-367r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From George.Penokie at lsi.com  Tue Oct 27 12:45:13 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 27 Oct 2009 13:45:13 -0600
Subject: FW: (Forward to attendees) Meeting invitation: SPL proposals review
 Oct. 28th
Message-ID: <mailman.701.1441607351.22516.t10@sandbox.t10.org>

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

Reminder that there will be an SPL meeting on Oct. 28th at 10 AM central
time. Call-in and WebEx information is below. The following is a list of
proposals that need to be addressed. We will cover as much many as possible
in the call.
SPL proposals that need to be resolved before letter ballot::
	    SPL - Arbitration Priority Simplification for Expanders
(09-240r3) [Tabor]
	    SPL - STP extended buffer support (09-268r4) [Symons]
	    SPL: - Fix SMP Zone Lock while zoning disabled (09-317r2)
[Besmer]
	    SPL - Zone Persistence Fix (09-358r1) [Tabor]
	    SPL: - Miscellaneous Fixes (09-374r1) [Penokie]
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
From: George Penokie [mailto:messenger at webex.com]
Sent: Thursday, October 15, 2009 2:07 PM
To: Penokie, George
Subject: (Forward to attendees) Meeting invitation: SPL proposals review
**** You can forward this email invitation to attendees ****
Hello ,
George Penokie invites you to attend this online meeting.
Topic: SPL proposals review
Date: Wednesday, October 28, 2009
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago)
Meeting Number: 571 472 131
Meeting Password: Buffer01
Please click the link below to see more information, or to join the meeting.
-------------------------------------------------------
To join the online meeting (Now from iPhones too!)
-------------------------------------------------------
1. Go to
https://lsilogic.webex.com/lsilogic/j.php?ED=132558402&UID=0&PW=7703f8b9486e1
b1c1e065e5d5f
2. Enter your name and email address.
3. Enter the meeting password: Buffer01
4. Click "Join Now".
-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Conference Access:
  Toll free:  1-866-214-7945
  Toll:       1-702-696-4029
Passcode:     5073289017
-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://lsilogic.webex.com/lsilogic/mc
2. On the left navigation bar, click "Support".
You can contact me at:
george.penokie at lsi.com
1-507-3289017
To add this meeting to your calendar program (for example Microsoft Outlook),
click this link:
https://lsilogic.webex.com/lsilogic/j.php?ED=132558402&UID=0&ICS=MI&LD=1&RD=2
&ST=1&SHA2=GuOmtLUepjM0E7faUG6pte6rYeH1OpBc4m9bNmTAuto=
The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in the
meeting, please check whether you have the players installed on your computer
by going to https://lsilogic.webex.com/lsilogic/systemdiagnosis.php
Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial
http://www.webex.com
We've got to start meeting like this(TM)
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, do not join the session.


From lohmeyer at t10.org  Wed Oct 28 01:00:01 2009
From: lohmeyer at t10.org (T10 List Manager)
Date: Wed, 28 Oct 2009 02:00:01 -0600
Subject: T10 Reflector Monthly Reminder
Message-ID: <mailman.702.1441607351.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 List Manager <lohmeyer at t10.org>
*
This is an automatic monthly posting to the T10 Reflector.  If you
receive this message, it means that you are subscribed to the T10
Reflector email list.
The T10 Reflector is provided by the SCSI Trade Association and
maintained by LSI Corp. This reflector exists to discuss INCITS
T10 Technical Committee issues and to disseminate T10-related
information (minutes, meeting notices, etc.).
---------------------------------------------------------------------------
You do not need to be an INCITS T10 Technical Committee member to
use this reflector, however you must agree to:
 * read the INCITS Patent Policy and the INCITS Antitrust Guidelines
 * acknowledge that the activities of the T10 Technical Committee are
   governed by the INCITS policies and procedures as specified in the
   reference documents RD-1 and RD-2
 * acknowledge that draft documents may change at any time, without notice.
The INCITS Patent Policy, the INCITS Antitrust Guidelines, the RD-1, and
the RD-2 are all available on the www.incits.org web site.
If you do not agree to the above conditions, then you must unsubscribe
to this reflector.
---------------------------------------------------------------------------
T10 Reflector is not intended to carry commercial traffic. People who post
advertisements, job offers, etc. will be removed from the reflector.
Please visit http://www.t10.org/t10r.htm for instructions on subscribing,
unsubscribing, or searching the T10 Reflector archives.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Barry.Olawsky at hp.com  Thu Oct 29 04:09:35 2009
From: Barry.Olawsky at hp.com (Olawsky, Barry)
Date: Thu, 29 Oct 2009 11:09:35 +0000
Subject: NO SFF-8449, SFF-8636 Conference Call Today, October 15, 2009
Message-ID: <mailman.703.1441607351.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Olawsky, Barry" <Barry.Olawsky at hp.com>
*
The SFF-8449, 8636 conference call has been canceled for today. The next call
will be November 5th, 2009.
Toll Free Dial in Number: (877)810-9442 International Access/Caller Paid Dial
In Number: (636)651-3190 PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate
Topic: SAS-2.1 PHY WG
Date: Thursday, November 5 2009
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) Meeting Number:
826 515 680 Meeting Password: newsas
(Note: When logging onto WEBEX, please include your company following your
name. This will help the person recording attendance.)
*
* 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 Oct 31 23:00:45 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 1 Nov 2009 00:00:45 -0600
Subject: Recent T10 documents uploaded since 2009/10/25
Message-ID: <mailman.704.1441607351.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC-3: SPC-4;  SAM-5; SCSI Referrals
(by: George Penokie)
T10/09-241r2   Uploaded: 2009/10/27   280840 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-241r2.pdf
SBC-3 # Thin Provisioning: Anchored
(by: David L. Black)
T10/09-272r1   Uploaded: 2009/10/26   279682 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-272r1.pdf
SPL: Fix SMP Zone Lock while zoning disabled
(by: Brad Besmer)
T10/09-317r2   Uploaded: 2009/10/25   93141 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-317r2.pdf
SSC-4 Volume Write Juncture MAM parameter
(by: Kevin Butt)
T10/09-366r0   Uploaded: 2009/10/26   59641 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-366r0.pdf
SSC-4 Volume Coherency MAM parameter
(by: Kevin Butt)
T10/09-367r0   Uploaded: 2009/10/26   81630 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-367r0.pdf
SPL: Miscellaneous Fixes
(by: George Penokie)
T10/09-374r1   Uploaded: 2009/10/27   74323 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-374r1.pdf
SPL: Miscellaneous Fixes
(by: George Penokie)
T10/09-374r2   Uploaded: 2009/10/28   74495 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-374r2.pdf
SPC-4: XCOPY - No LIST IDENTIFIER alternate
(by: David Black)
T10/09-378r0   Uploaded: 2009/10/26   164186 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-378r0.pdf
SPC-4: XCOPY - No LIST IDENTIFIER alternate
(by: David L. Black)
T10/09-378r1   Uploaded: 2009/10/28   166291 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-378r1.pdf
SPC-4 - Another Encryption MAM Attribute
(by: Curtis Ballard)
T10/09-379r0   Uploaded: 2009/10/27   77276 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-379r0.pdf
SBC: FORMAT UNIT command fix
(by: George Penokie)
T10/09-380r0   Uploaded: 2009/10/28   66301 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-380r0.pdf
Working Drafts
--------------
(Report generated on 2009/11/01 at 00:00:45)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org