From curtis.ballard at hp.com  Mon Jan  1 08:30:33 2007
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Mon, 1 Jan 2007 11:30:33 -0500
Subject: SMC-3 Clarification of reporting DTD prevented media removal posted
Message-ID: <mailman.0.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
At the SMC-3 teleconference it was noted that we needed a clarification
to when a SMC device must fail a move or exchange command and report
that the data transfer device has a prevent media removal condition set.
I have posted 07-015r0 with a proposal for the requested clarification
at:   http://www.t10.org/ftp/t10/document.07/07-015r0.pdf
Curtis Ballard
Hewlett Packard
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gop at us.ibm.com  Tue Jan  2 06:27:17 2007
From: gop at us.ibm.com (George Penokie)
Date: Tue, 2 Jan 2007 08:27:17 -0600
Subject: question about reservation and persistent reservation
Message-ID: <mailman.1.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701020_f.htm">HTML-formatted message</A>

Ming,
Reservations and persistent reservations are both I_T nexus based. The 
question that has to be answered is; What has the iSCSI protocol defined 
as the initiator port (i.e., the I) and the target port (i.e., the T). 
>From SAMs point of view as long as the connection is between the same I 
and T that holds the reservation then the command is valid regardless of 
the actual physical path that is used (i.e., there can be any number of 
physical paths between a single initiator port and a single target port).
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
Ming Zhang <blackmagic02881 at gmail.com> 
Sent by: owner-t10 at t10.org
12/28/2006 10:21 AM
Please respond to
blackmagic02881 at gmail.com
To
t10 at t10.org
cc
Arne Redlich <agr at powerkom-dd.de>, Juhani Rautiainen <jrauti at iki.fi>, 
Steffen Plotner <swplotner at amherst.edu>, "Ross S. W. Walker" 
<rwalker at medallion.com>
Subject
question about reservation and persistent reservation
* From the T10 Reflector (t10 at t10.org), posted by:
* Ming Zhang <blackmagic02881 at gmail.com>
*
Hi All
We try to add reservation support to an iSCSI target and have some
questions about reservation.
Reservation is per nexus or per initiator? persistent reservation is per
nexus or per initiator?
Our dilemma is like this. between an iSCSI initiator and target,
multipath IO can (1) has multiple sessions over to same target via
different physical NICs and paths. or (2) has one session with multiple
connections, with each connection over different paths. Base on iSCSI
RFC, (1) will have multiple I_L nexus while (2) only have 1 nexus.
Then for reservation support via RESERVE_6/10, if one initiator reserve
one LU via one session, can this initiator send WRITE or other commands
via another session?
Thanks
Ming
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From blackmagic02881 at gmail.com  Tue Jan  2 06:38:54 2007
From: blackmagic02881 at gmail.com (Ming Zhang)
Date: Tue, 02 Jan 2007 09:38:54 -0500
Subject: question about reservation and persistent reservation
Message-ID: <mailman.2.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ming Zhang <blackmagic02881 at gmail.com>
*
Hi George
Thanks for answering my question.
>From iSCSI RFC (http://www.faqs.org/rfcs/rfc3720.html)
I_T nexus: According to [SAM2], the I_T nexus is a relationship
     between a SCSI Initiator Port and a SCSI Target Port.  For iSCSI,
     this relationship is a session, defined as a relationship between
     an iSCSI Initiator's end of the session (SCSI Initiator Port) and
     the iSCSI Target's Portal Group.  The I_T nexus can be identified
     by the conjunction of the SCSI port names; that is, the I_T nexus
     identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI
     Target Name + ',t,'+ Portal Group Tag).
Why? In iSCSI, if one iSCSI initiator setup 2 or more sessions with
_same_ target, i could not see any negative effect that commands can not
send through all sessions to same target from same initiator.
Or one step ahead, when SCSI spec is defined, why reservation need to be
nexus based (between initiator port and target port), not between
initiator and target, for multiple port situation?
Ming
On Tue, 2007-01-02 at 08:27 -0600, George Penokie wrote:
> 
> Ming, 
> 
> Reservations and persistent reservations are both I_T nexus based. The
> question that has to be answered is; What has the iSCSI protocol
> defined as the initiator port (i.e., the I) and the target port (i.e.,
> the T). From SAMs point of view as long as the connection is between
> the same I and T that holds the reservation then the command is valid
> regardless of the actual physical path that is used (i.e., there can
> be any number of physical paths between a single initiator port and a
> single target port). 
> 
> Bye for now,
> George Penokie
> 
> Dept 9A8 030-3 A410
> E-Mail:    gop at us.ibm.com
> Internal:  553-5208
> External: 507-253-5208 
> 
> 
> Ming Zhang
> <blackmagic02881 at gmail.com> 
> Sent by: owner-t10 at t10.org 
> 
> 12/28/2006 10:21 AM 
>	   Please respond to
>      blackmagic02881 at gmail.com
> 
> 
> 
> 
>		 To
> t10 at t10.org 
>		 cc
> Arne Redlich
> <agr at powerkom-dd.de>, Juhani Rautiainen <jrauti at iki.fi>, Steffen Plotner
<swplotner at amherst.edu>, "Ross S. W. Walker" <rwalker at medallion.com> 
>	    Subject
> question about
> reservation and
> persistent
> reservation
> 
> 
> 
> 
> 
> 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ming Zhang <blackmagic02881 at gmail.com>
> *
> Hi All
> 
> We try to add reservation support to an iSCSI target and have some
> questions about reservation.
> 
> Reservation is per nexus or per initiator? persistent reservation is
> per
> nexus or per initiator?
> 
> Our dilemma is like this. between an iSCSI initiator and target,
> multipath IO can (1) has multiple sessions over to same target via
> different physical NICs and paths. or (2) has one session with
> multiple
> connections, with each connection over different paths. Base on iSCSI
> RFC, (1) will have multiple I_L nexus while (2) only have 1 nexus.
> 
> Then for reservation support via RESERVE_6/10, if one initiator
> reserve
> one LU via one session, can this initiator send WRITE or other
> commands
> via another session?
> 
> 
> Thanks
> 
> Ming
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
-- 
http://blackmagic02881.wordpress.com/
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gop at us.ibm.com  Tue Jan  2 07:12:44 2007
From: gop at us.ibm.com (George Penokie)
Date: Tue, 2 Jan 2007 09:12:44 -0600
Subject: question about reservation and persistent reservation
Message-ID: <mailman.3.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701022_f.htm">HTML-formatted message</A>

Ming,
Reservations (not persistent reservations) were defined long before that 
was any such thing as multiple port devices and as such is not well suited 
for use is such environments. That is one of the reasons reservations no 
longer defined in the current SCSI specifications and were replaced with 
persistent reservations.
In the process of defining persistent reservations is was not clear in the 
standards as to what the reservations were associated with. At the same 
time the SCSI architecture was moving from a parallel based architecture 
to a serial based architecture. That change required a clear delineation 
between ports and devices that was not previously necessary. The end 
result is that the I_T nexus became a port to port definition and that 
made all reservations port to port.
I would suggest the only reasonable solution is the use of persistent 
reservations in environments that contain multi-ported SCSI devices.
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
Ming Zhang <blackmagic02881 at gmail.com> 
01/02/2007 08:38 AM
Please respond to
blackmagic02881 at gmail.com
To
George Penokie/Rochester/IBM at IBMUS
cc
Arne Redlich <agr at powerkom-dd.de>, Juhani Rautiainen <jrauti at iki.fi>, 
owner-t10 at t10.org, "Ross S. W. Walker" <rwalker at medallion.com>, Steffen 
Plotner <swplotner at amherst.edu>, t10 at t10.org
Subject
Re: question about reservation and persistent reservation
Hi George
Thanks for answering my question.
>From iSCSI RFC (http://www.faqs.org/rfcs/rfc3720.html)
I_T nexus: According to [SAM2], the I_T nexus is a relationship
     between a SCSI Initiator Port and a SCSI Target Port.  For iSCSI,
     this relationship is a session, defined as a relationship between
     an iSCSI Initiator's end of the session (SCSI Initiator Port) and
     the iSCSI Target's Portal Group.  The I_T nexus can be identified
     by the conjunction of the SCSI port names; that is, the I_T nexus
     identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI
     Target Name + ',t,'+ Portal Group Tag).
Why? In iSCSI, if one iSCSI initiator setup 2 or more sessions with
_same_ target, i could not see any negative effect that commands can not
send through all sessions to same target from same initiator.
Or one step ahead, when SCSI spec is defined, why reservation need to be
nexus based (between initiator port and target port), not between
initiator and target, for multiple port situation?
Ming
On Tue, 2007-01-02 at 08:27 -0600, George Penokie wrote:
> 
> Ming, 
> 
> Reservations and persistent reservations are both I_T nexus based. The
> question that has to be answered is; What has the iSCSI protocol
> defined as the initiator port (i.e., the I) and the target port (i.e.,
> the T). From SAMs point of view as long as the connection is between
> the same I and T that holds the reservation then the command is valid
> regardless of the actual physical path that is used (i.e., there can
> be any number of physical paths between a single initiator port and a
> single target port). 
> 
> Bye for now,
> George Penokie
> 
> Dept 9A8 030-3 A410
> E-Mail:    gop at us.ibm.com
> Internal:  553-5208
> External: 507-253-5208 
> 
> 
> Ming Zhang
> <blackmagic02881 at gmail.com> 
> Sent by: owner-t10 at t10.org 
> 
> 12/28/2006 10:21 AM 
>	   Please respond to
>      blackmagic02881 at gmail.com
> 
> 
> 
> 
>		 To
> t10 at t10.org 
>		 cc
> Arne Redlich
> <agr at powerkom-dd.de>, Juhani Rautiainen <jrauti at iki.fi>, Steffen Plotner 
<swplotner at amherst.edu>, "Ross S. W. Walker" <rwalker at medallion.com> 
>	    Subject
> question about
> reservation and
> persistent
> reservation
> 
> 
> 
> 
> 
> 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ming Zhang <blackmagic02881 at gmail.com>
> *
> Hi All
> 
> We try to add reservation support to an iSCSI target and have some
> questions about reservation.
> 
> Reservation is per nexus or per initiator? persistent reservation is
> per
> nexus or per initiator?
> 
> Our dilemma is like this. between an iSCSI initiator and target,
> multipath IO can (1) has multiple sessions over to same target via
> different physical NICs and paths. or (2) has one session with
> multiple
> connections, with each connection over different paths. Base on iSCSI
> RFC, (1) will have multiple I_L nexus while (2) only have 1 nexus.
> 
> Then for reservation support via RESERVE_6/10, if one initiator
> reserve
> one LU via one session, can this initiator send WRITE or other
> commands
> via another session?
> 
> 
> Thanks
> 
> Ming
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
-- 
http://blackmagic02881.wordpress.com/


From blackmagic02881 at gmail.com  Tue Jan  2 07:24:04 2007
From: blackmagic02881 at gmail.com (Ming Zhang)
Date: Tue, 02 Jan 2007 10:24:04 -0500
Subject: question about reservation and persistent reservation
Message-ID: <mailman.4.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ming Zhang <blackmagic02881 at gmail.com>
*
Hi George
On Tue, 2007-01-02 at 09:12 -0600, George Penokie wrote:
> 
> Ming, 
> 
> Reservations (not persistent reservations) were defined long before
> that was any such thing as multiple port devices and as such is not
> well suited for use is such environments. That is one of the reasons
> reservations no longer defined in the current SCSI specifications and
> were replaced with persistent reservations. 
make sense. we guessed it is too old to fit today's world.
> 
> In the process of defining persistent reservations is was not clear in
> the standards as to what the reservations were associated with. At the
> same time the SCSI architecture was moving from a parallel based
> architecture to a serial based architecture. That change required a
> clear delineation between ports and devices that was not previously
> necessary. The end result is that the I_T nexus became a port to port
> definition and that made all reservations port to port. 
> 
> I would suggest the only reasonable solution is the use of persistent
> reservations in environments that contain multi-ported SCSI devices. 
but if all reservations (even persistent reservation) port to port, then
this issue is still not solved in a reasonable way, why a target should
reject a request from _same_ initiator who holds reservation but
different port?
even the reservation key is to identified the _only_ nexus and can not
be borrowed by another nexus between _same_ initiator and target right?
>   
> Bye for now,
> George Penokie
> 
> Dept 9A8 030-3 A410
> E-Mail:    gop at us.ibm.com
> Internal:  553-5208
> External: 507-253-5208 
> 
> 
> Ming Zhang
> <blackmagic02881 at gmail.com> 
> 
> 01/02/2007 08:38 AM 
>	   Please respond to
>      blackmagic02881 at gmail.com
> 
> 
> 
> 
>		 To
> George
> Penokie/Rochester/IBM at IBMUS 
>		 cc
> Arne Redlich
> <agr at powerkom-dd.de>, Juhani Rautiainen <jrauti at iki.fi>, owner-t10 at t10.org,
"Ross S. W. Walker" <rwalker at medallion.com>, Steffen Plotner
<swplotner at amherst.edu>, t10 at t10.org 
>	    Subject
> Re: question
> about reservation
> and persistent
> reservation
> 
> 
> 
> 
> 
> 
> 
> 
> Hi George
> 
> Thanks for answering my question.
> 
> >From iSCSI RFC (http://www.faqs.org/rfcs/rfc3720.html)
> I_T nexus: According to [SAM2], the I_T nexus is a relationship
>     between a SCSI Initiator Port and a SCSI Target Port.  For iSCSI,
>     this relationship is a session, defined as a relationship between
>     an iSCSI Initiator's end of the session (SCSI Initiator Port) and
>     the iSCSI Target's Portal Group.	The I_T nexus can be identified
>     by the conjunction of the SCSI port names; that is, the I_T nexus
>     identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI
>     Target Name + ',t,'+ Portal Group Tag).
> 
> Why? In iSCSI, if one iSCSI initiator setup 2 or more sessions with
> _same_ target, i could not see any negative effect that commands can
> not
> send through all sessions to same target from same initiator.
> 
> Or one step ahead, when SCSI spec is defined, why reservation need to
> be
> nexus based (between initiator port and target port), not between
> initiator and target, for multiple port situation?
> 
> Ming
> 
> 
> On Tue, 2007-01-02 at 08:27 -0600, George Penokie wrote:
> > 
> > Ming, 
> > 
> > Reservations and persistent reservations are both I_T nexus based.
> The
> > question that has to be answered is; What has the iSCSI protocol
> > defined as the initiator port (i.e., the I) and the target port
> (i.e.,
> > the T). From SAMs point of view as long as the connection is between
> > the same I and T that holds the reservation then the command is
> valid
> > regardless of the actual physical path that is used (i.e., there can
> > be any number of physical paths between a single initiator port and
> a
> > single target port). 
> > 
> > Bye for now,
> > George Penokie
> > 
> > Dept 9A8 030-3 A410
> > E-Mail:    gop at us.ibm.com
> > Internal:  553-5208
> > External: 507-253-5208 
> > 
> > 
> > Ming Zhang
> > <blackmagic02881 at gmail.com> 
> > Sent by: owner-t10 at t10.org 
> > 
> > 12/28/2006 10:21 AM 
> >	     Please respond to
> >	 blackmagic02881 at gmail.com
> > 
> > 
> > 
> > 
> >		   To
> > t10 at t10.org 
> >		   cc
> > Arne Redlich
> > <agr at powerkom-dd.de>, Juhani Rautiainen <jrauti at iki.fi>, Steffen
> Plotner <swplotner at amherst.edu>, "Ross S. W. Walker"
> <rwalker at medallion.com> 
> >	      Subject
> > question about
> > reservation and
> > persistent
> > reservation
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > * From the T10 Reflector (t10 at t10.org), posted by:
> > * Ming Zhang <blackmagic02881 at gmail.com>
> > *
> > Hi All
> > 
> > We try to add reservation support to an iSCSI target and have some
> > questions about reservation.
> > 
> > Reservation is per nexus or per initiator? persistent reservation is
> > per
> > nexus or per initiator?
> > 
> > Our dilemma is like this. between an iSCSI initiator and target,
> > multipath IO can (1) has multiple sessions over to same target via
> > different physical NICs and paths. or (2) has one session with
> > multiple
> > connections, with each connection over different paths. Base on
> iSCSI
> > RFC, (1) will have multiple I_L nexus while (2) only have 1 nexus.
> > 
> > Then for reservation support via RESERVE_6/10, if one initiator
> > reserve
> > one LU via one session, can this initiator send WRITE or other
> > commands
> > via another session?
> > 
> > 
> > Thanks
> > 
> > Ming
> > 
> > 
> > *
> > * For T10 Reflector information, send a message with
> > * 'info t10' (no quotes) in the message body to majordomo at t10.org
> > 
> -- 
> http://blackmagic02881.wordpress.com/
> 
> 
-- 
http://blackmagic02881.wordpress.com/
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Alvin.Cox at seagate.com  Tue Jan  2 08:04:00 2007
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Tue, 2 Jan 2007 10:04:00 -0600
Subject: Reminder: SAS PHY call 1/4/07, 10 am CST
Message-ID: <mailman.5.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701024_f.htm">HTML-formatted message</A>

Next call 1/4/07.
Weekly teleconferences scheduled for Thursdays at 10 am CST: 
PARTICIPANT INFORMATION: 
Toll Free Dial in Number: (866) 279-4742 
International Access/Caller Paid Dial In Number: (309) 229-0118 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Agenda:
1. Use of mode and pk-to-pk to measure de-emphasis.
Mode defined in 07-010r0
Reference proposals/documents:
http://www.t10.org/ftp/t10/document.07/07-010r0.pdf
http://www.t10.org/ftp/t10/document.07/07-001r0.pdf
http://www.t10.org/ftp/t10/document.06/06-496r2.pdf
2. 1300mV versus 1200mV max pk-to-pk voltage spec. [Witt]
3. Status on previous actions:
a. Barry will make some measurements to determine if the low frequency 
issues are being captured. 
b. Barry to propose a set of loss values for a zero length test load.
c. Barry to find out whether the office environment is under Class A or 
Class B requirements.
4. Review of Proposed 6G SAS Phy Specs for EMI Reduction [Jenkins]
http://www.t10.org/ftp/t10/document.07/07-007r1.pdf, and
http://www.t10.org/ftp/t10/document.07/07-007r1.ppt 
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From Frederick.Knight at netapp.com  Tue Jan  2 08:54:43 2007
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Tue, 2 Jan 2007 11:54:43 -0500
Subject: question about reservation and persistent reservation
Message-ID: <mailman.6.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
> In the process of defining persistent reservations is was not clear in
> the standards as to what the reservations were associated with. At the
> same time the SCSI architecture was moving from a parallel based 
> architecture to a serial based architecture. That change required a 
> clear delineation between ports and devices that was not previously 
> necessary. The end result is that the I_T nexus became a port to port 
> definition and that made all reservations port to port.
> 
> I would suggest the only reasonable solution is the use of persistent 
> reservations in environments that contain multi-ported SCSI devices.
but if all reservations (even persistent reservation) port to port, then
this issue is still not solved in a reasonable way, why a target should
reject a request from _same_ initiator who holds reservation but
different port?
>> This is exactly what you want.  Each host O/W must control all the
paths
>> from the host to the device.  There may be times when the host needs
to
>> stop I/O on only one path.  The way the host does that is via a
PREEMPT
>> PR function that impacts only that one path.
>>
>> To do that, each path must register with a unique key.  When the same
key
>> is used, the PREEMPT will impact all paths using that key.  So the
spec
>> allows the host to have whatever level of control it wants (such as a
>> common key for many paths, or a unique key for each path).
>>
even the reservation key is to identified the _only_ nexus and can not
be borrowed by another nexus between _same_ initiator and target right?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Tue Jan  2 08:44:30 2007
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Tue, 2 Jan 2007 11:44:30 -0500
Subject: question about reservation and persistent reservation
Message-ID: <mailman.7.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
In my experience, reservations are supposed to be I_T_L nexus based.
So in your case 1, a reserve down 1 path (one session) and an I/O
down the other path (different session), the I/O should get an error
(RESERVATION CONFLICT).  The original SPC (section 5.4) spec (1997)
contains the statement:
"For multiple port implementations, devices on other ports (i.e., the
ports that do not include the initiator to which the reservation has
been granted) also shall be denied access to the logical unit as
described in the preceding paragraph."
The SPC-2 (section 5.6) spec clarifies this further by saying:
"For the purposes of handling reservations, other initiators are
defined as all initiators on the same service delivery port except
the initiator holding the reservation and all initiators on all
other service delivery ports."
But, it's not clear where the () belong.  Consider:
If 1 = "all initiators on the same service delivery port"
and 2 = "the initiator holding the reservation"
and 3 = "all initiators on all other service delivery ports"
Do you get:
A: "other initiators = 1 except (2 and 3)" - an I_L reserve
or
B: "other initiators = "(1 except 2) and 3" - an I_T_L reserve
I am aware of some devices that ignore the "T" part of the nexus
(case "A" above).  So, once an "I" does a RESERVE 6/10, that "I"
can then communicate with any "T" that exists on the device without
getting a RESERVATION CONFLICT.
There were not many multi-port devices around when the old RESERVE/
RELEASE 6/10 existed.  And so, when some multi-port devices started
to show up, some designers decided for reservation purposes, to treat
the ports as if they were all the same (method "A" above).
In your case 2, with a single I_T_L nexus, a reserve and a write are
going down the same path (they may go over different connections, but
it is the same I_T_L nexus) so there is no error (no RESERVATION
CONFLICT).  This case is pretty clear, and it doesn't matter if it's
the old SCSI-2 reservations, or the new PR reservations.
SCSI can only impact what it can see (and SCSI can not see the other
connections in the single session, those connections are part of the
service deliver subsystem, and are transparent to the SCSI layer).
PR is more clear.  But, when it comes to Persistent Reservations,
you need to consider the SPEC_I_PT (where the host can give you a
list of initiator IDs and the ALL_TG_PT bit (where the reservation
applies to all target ports, not just the one receiving the command).
Without ALL_TG_PT, then the command applies to only the one I_T_L
nexus over which the command was transferred.  But, these bits are
optional.  If you do not support those bits, then all you have is
the I_T_L nexus.
	Fred Knight
-----Original Message-----
From: Ming Zhang [mailto:blackmagic02881 at gmail.com] 
Sent: Thursday, December 28, 2006 11:22 AM
To: t10 at t10.org
Cc: Arne Redlich; Juhani Rautiainen; Steffen Plotner; Ross S. W. Walker
Subject: question about reservation and persistent reservation
* From the T10 Reflector (t10 at t10.org), posted by:
* Ming Zhang <blackmagic02881 at gmail.com>
*
Hi All
We try to add reservation support to an iSCSI target and have some
questions about reservation.
Reservation is per nexus or per initiator? persistent reservation is per
nexus or per initiator?
Our dilemma is like this. between an iSCSI initiator and target,
multipath IO can (1) has multiple sessions over to same target via
different physical NICs and paths. or (2) has one session with multiple
connections, with each connection over different paths. Base on iSCSI
RFC, (1) will have multiple I_L nexus while (2) only have 1 nexus.
Then for reservation support via RESERVE_6/10, if one initiator reserve
one LU via one session, can this initiator send WRITE or other commands
via another session?
Thanks
Ming
*
* 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 lohmeyer at t10.org  Tue Jan  2 11:53:31 2007
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 02 Jan 2007 12:53:31 -0700
Subject: Fwd: INCITS/T10 International Representative - Third Call for
  Volunteers -  Closes February 2, 2007
Message-ID: <mailman.8.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701027_f.htm">HTML-formatted message</A>

This is the third call for volunteers to serve as the T10 International
Representative. As Jennifer mentions below, a candidate has come forth.
However, the call is open to any other T10 member who might wish to apply for
this position. Please contact me if you have any questions.
John 
>X-Ninja-PIM: Scanned by Ninja
>X-Ninja-AttachmentFiltering: (no action)
>Subject: INCITS/T10 International Representative - Third Call for Volunteers
- 
>	 Closes February 2, 2007
>Date: Tue, 2 Jan 2007 14:36:32 -0500
>Thread-Topic: INCITS/T10 International Representative - Third Call for
Volunteers - Closes February 2, 2007
>Thread-Index: AccupU5I6n3Wx8xoRXCKDh7LkBt1Aw==
>Importance: high
>From: "Garner, Jennifer" <jgarner at itic.org>
>To: John Lohmeyer <lohmeyer at t10.org>
>Cc: "Robinson, Gary" <g.robinson at computer.org>,
>	 "Barra, Lynn" <lbarra at itic.org>,
>	 "Purnell, Parthenia" <ppurnell at itic.org>
>Priority: Urgent
>X-pstn-levels:     (S:99.90000/99.90000 R:95.9108 P:95.9108 M:97.0282
C:98.6951 )
>X-pstn-settings: 3 (1.0000:1.0000) s gt3 gt2 gt1 r p m c 
>X-pstn-addresses: from <jgarner at itic.org> [22/1] 
>X-pstn-levels:     (S:99.90000/99.90000 R:95.9108 P:95.9108 M:97.0282
C:98.6951 )
>X-pstn-settings: 3 (1.0000:1.0000) s gt3 gt2 gt1 r p m c 
>X-pstn-addresses: from <jgarner at itic.org> [20/1] 
>X-Scanned-By: MIMEDefang 2.39
>X-OriginalArrivalTime: 02 Jan 2007 19:36:39.0560 (UTC)
FILETIME=[52B7B080:01C72EA5]
>
>John 
>
> 
>
>As you may recall, the first two calls for volunteers to serve as T10 IR
closed without response, however, a candidate has come forth.
>
> 
>
>At your earliest opportunity, please issue the attached third call to the
members of T10.  I will be in touch after the call has closed on February 2.
>
> 
>
>Best regards -
>
> 
>
>Jennifer T. Garner
>Associate Director, Standards Programs
>INCITS/Information Technology Industry Council
>1250 Eye Street, NW - Suite 200
>Washington, DC 20005
>202.626.5737
>e-mail:   jgarner at itic.org
>website: <www.incits.org">http://www.incits.org>www.incits.org
>
> 
>
> 
>
>============================================================================
====
>
>in070003
>
>INCITS
>InterNational Committee for Information Technology Standards
>INCITS Secretariat, Information Technology Industry Council (ITI)
>1250 Eye St. NW, Suite 200, Washington, DC 20005
>Telephone 202-737-8888; Fax 202-638-4922
>
>Date: January 2, 2007
>Date Due: February 2, 2007
>Replaces:  in061167, in061278, in061417
>Reply to: Jennifer T. Garner 
>Phone: (202) 626-5737 
>email: jgarner at itic.org
>cc:   John Lohmeyer, INCITS/T10 Chairman
>	 Gary Robinson, INCITS/T10 IR	     
>
>----------
>To: The Members of INCITS/T10
>
>From: Jennifer T. Garner, for the INCITS Secretariat
>
>Subject: THIRD CALL FOR VOLUNTEERS - International Representative -
INCITS/T10, SCSI Storage Interfaces
>
>----------
>
>The term of office of the current INCITS/T10 International Representative,
Mr. Gary Robinson, will expire in March 2007.  The first two calls for
volunteers to serve as International Representative of INCITS/T10 closed
without response.  A candidate has come forth.
>
>This third call for volunteers to serve as International Representative of
INCITS/T10 is being issued to the members of T10 and will close on February
2, 2007. 
>
>Any member of the INCITS Subgroup is welcome to volunteer to serve. Before
one considers doing so, however, the commitment in time and responsibilities
should be considered. Officers must actively support the administrative
structure that ensures due process to all participants, assists in reaching
consensus and protects the accreditation of the entire system. [There is no
limit to the number of terms an individual may serve. There is a rule
prohibiting one individual from being appointed to two or more offices of the
same committee simultaneously.]
>
>The <INCITS/RD-2">http://www.incits.org/rd2/main.htm>INCITS/RD-2, Organization and
Procedures of INCITS, generally describes officers' responsibilities, and a
more detailed list of duties has been compiled in the
<INCITS/RD-3">http://www.incits.org/rd3/rd3.htm>INCITS/RD-3, Officers' Guide.
>
>Those willing to make this commitment must submit three written statements
in support of their candidacy: 
>    * A one-page statement of experience, indicating the volunteer's
expertise in the subgroup's program of work, voluntary standards efforts,
committee experience and leadership abilities (to be forwarded to the INCITS
Subgroup for an advisory ballot if there is more than one candidate). 
>    * A statement of management support for a three-year term on company
letterhead acknowledging the additional workload, financial resources and
duties required of an officer over and above that of a technical participant.
 This statement must be signed by the candidate's management and submitted on
their organization's letterhead.  
>
>The statement of management support for the three-year term is a good faith
commitment, not a legal binding commitment. If future circumstances require
the applicant to resign from the office before the term has been fulfilled,
this will be accepted without prejudice. 
>    * A statement as to whether or not the candidate is a representative of
a U.S. domiciled organization.	
>
>Any supplemental materials will be forwarded along with the advisory ballot
to INCITS, which appoints all INCITS Subgroup officers. The statements from
candidates wishing to serve in the above referenced position on the INCITS
Subgroup should be sent to the attention of Jennifer Garner
(jgarner at itic.org) no later than February 2, 2007. 
>
>
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907


From gop at us.ibm.com  Tue Jan  2 13:44:32 2007
From: gop at us.ibm.com (George Penokie)
Date: Tue, 2 Jan 2007 15:44:32 -0600
Subject: SAS-2: Expander Notification of Temporary Shutdown proposal (T10/07-008r3)
Message-ID: <mailman.9.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701028_f.htm">HTML-formatted message</A>

I have created another rev which cleans up some inconsistences that where 
created in my haste to get something out before the holidays. If you have 
any comments let me know.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.07/07-008r3.pdf
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208


From blackmagic02881 at gmail.com  Tue Jan  2 16:41:34 2007
From: blackmagic02881 at gmail.com (Ming Zhang)
Date: Tue, 02 Jan 2007 19:41:34 -0500
Subject: question about reservation and persistent reservation
Message-ID: <mailman.10.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ming Zhang <blackmagic02881 at gmail.com>
*
On Tue, 2007-01-02 at 11:54 -0500, Knight, Frederick wrote:
> > In the process of defining persistent reservations is was not clear in
> 
> > the standards as to what the reservations were associated with. At the
> 
> > same time the SCSI architecture was moving from a parallel based 
> > architecture to a serial based architecture. That change required a 
> > clear delineation between ports and devices that was not previously 
> > necessary. The end result is that the I_T nexus became a port to port 
> > definition and that made all reservations port to port.
> > 
> > I would suggest the only reasonable solution is the use of persistent 
> > reservations in environments that contain multi-ported SCSI devices.
> 
> but if all reservations (even persistent reservation) port to port, then
> this issue is still not solved in a reasonable way, why a target should
> reject a request from _same_ initiator who holds reservation but
> different port?
> 
> >> This is exactly what you want.  Each host O/W must control all the
> paths
> >> from the host to the device.  There may be times when the host needs
> to
> >> stop I/O on only one path.  The way the host does that is via a
> PREEMPT
> >> PR function that impacts only that one path.
> >>
> >> To do that, each path must register with a unique key.  When the same
> key
> >> is used, the PREEMPT will impact all paths using that key.  So the
> spec
> >> allows the host to have whatever level of control it wants (such as a
> >> common key for many paths, or a unique key for each path).
thanks a lot for this and the explanation in another email. i think i
grasp the idea now.
> >>
> 
> even the reservation key is to identified the _only_ nexus and can not
> be borrowed by another nexus between _same_ initiator and target right?
> 
-- 
http://blackmagic02881.wordpress.com/
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Paul.Suhler at Quantum.Com  Tue Jan  2 17:13:39 2007
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Tue, 2 Jan 2007 17:13:39 -0800
Subject: T10/06-412r2 Posted:  SSC-3 Encryption KAD Lengths, Nonces, and Resets 
Message-ID: <mailman.11.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r070102a_f.htm">HTML-formatted message</A>

I have uploaded the above document for the SSC-3 working group meeting
in Orlando.  It should soon be available at: 
http://www.t10.org/ftp/t10/document.06/06-412r2.pdf
<http://www.t10.org/ftp/t10/document.06/06-412r2.pdf&gt; 
Thanks,
Paul Suhler
Quantum


From CLyon at scsita.org  Wed Jan  3 12:18:20 2007
From: CLyon at scsita.org (Chris Lyon)
Date: Wed, 03 Jan 2007 12:18:20 -0800
Subject: Reservation Link for March T-10 meeting
Message-ID: <mailman.12.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701030_f.htm">HTML-formatted message</A>

STA and T-10 members,
I understand some of you have been having problems booking the hotel  
for the March meeting. Please click on any of the links below and you  
should not have any other problems. The rate will come up 165.50.
Sorry for any confusion
Chris Lyon
>
> Greetings:
>
>
> Simply cut and paste any of the three links below and include with  
> your electronic correspondence to facilitate the reservation	
> process. Your guests will be directed to the property's home page  
> with the code already entered in the appropriate field. All they  
> need to do is enter their arrival date to begin the reservation  
> process.
>
> Memphis Marriott Downtown >>
>
>
>
> http://marriott.com/property/propertypage/memdt? 
> groupCode=scsscsa&app=resvlink
>
>
>
-=-=-=-=-=-=- SCSI Trade Association -=-=-=-=-=-=-
Chris Lyon, CAE 			Tel. +1.425.286.1111
Executive Director			Fax +1.425.488.3646
18221 102nd Ave N.E.		  E-mail: Clyon at scsita.org
Bothell, WA 98011		       http://www.scsita.org
The SCSI Trade Association is managed by LoBue & Majdalany Management  
Group, an IAAMC Charter Accredited  
Firm._______________________________________________


From CLyon at scsita.org  Wed Jan  3 12:18:20 2007
From: CLyon at scsita.org (Chris Lyon)
Date: Wed, 03 Jan 2007 12:18:20 -0800
Subject: [STA Members] Reservation Link for March T-10 meeting
Message-ID: <mailman.13.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701031_f.htm">HTML-formatted message</A>

STA and T-10 members,
I understand some of you have been having problems booking the hotel  
for the March meeting. Please click on any of the links below and you  
should not have any other problems. The rate will come up 165.50.
Sorry for any confusion
Chris Lyon
>
> Greetings:
>
>
> Simply cut and paste any of the three links below and include with  
> your electronic correspondence to facilitate the reservation	
> process. Your guests will be directed to the property's home page  
> with the code already entered in the appropriate field. All they  
> need to do is enter their arrival date to begin the reservation  
> process.
>
> Memphis Marriott Downtown >>
>
>
>
> http://marriott.com/property/propertypage/memdt? 
> groupCode=scsscsa&app=resvlink
>
>
>
-=-=-=-=-=-=- SCSI Trade Association -=-=-=-=-=-=-
Chris Lyon, CAE 			Tel. +1.425.286.1111
Executive Director			Fax +1.425.488.3646
18221 102nd Ave N.E.		  E-mail: Clyon at scsita.org
Bothell, WA 98011		       http://www.scsita.org
The SCSI Trade Association is managed by LoBue & Majdalany Management  
Group, an IAAMC Charter Accredited  
Firm._______________________________________________


From David.Peterson at mcdata.com  Fri Jan  5 10:25:49 2007
From: David.Peterson at mcdata.com (David Peterson)
Date: Fri, 5 Jan 2007 11:25:49 -0700
Subject: FCP-4: January working group meeting cancelled / SSC-3 to start at 
	11:00am
Message-ID: <mailman.14.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701050_f.htm">HTML-formatted message</A>

Howdy All,
The January FCP-4 working group meeting that was to be held on tuesday
January 16th at 9:00am in Orlando has been cancelled.
The SSC-3 working group meeting on tuesday January 16th in Orlando will
start at 11:00am.
Thanks...Dave
(no disclaimer)


From lohmeyer at t10.org  Sat Jan  6 23:03:38 2007
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 7 Jan 2007 00:03:38 -0700
Subject: Recent T10 documents uploaded since 2006/12/31
Message-ID: <mailman.15.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SSC-3: Key Entry using Encapsulating Security Payload (ESP)
(by: Matt Ball)
T10/06-225r4   Uploaded: 2007/01/02   57630 bytes
ftp://ftp.t10.org/t10/document.06/06-225r4.pdf
SMC-3 Error codes overview
(by: Noud Snelder)
T10/06-397r1   Uploaded: 2007/01/05   17545 bytes
ftp://ftp.t10.org/t10/document.06/06-397r1.pdf
SSC-3 Encryption KAD Lengths, Nonces, and Resets
(by: Paul Suhler)
T10/06-412r2   Uploaded: 2007/01/02   26047 bytes
ftp://ftp.t10.org/t10/document.06/06-412r2.pdf
SMC-3 Add PREVENT ALLOW MEDIA REMOVAL command
(by: Noud Snelder)
T10/06-442r1   Uploaded: 2007/01/03   29116 bytes
ftp://ftp.t10.org/t10/document.06/06-442r1.pdf
SPC-4: Establishing a Security Association using IKEv2
(by: Matt Ball & David Black)
T10/06-449r1   Uploaded: 2007/01/03   164447 bytes
ftp://ftp.t10.org/t10/document.06/06-449r1.pdf
ADC-2 Letter Ballot Comment Resolution
(by: Paul Entzel)
T10/06-475r1   Uploaded: 2007/01/05   169344 bytes
ftp://ftp.t10.org/t10/document.06/06-475r1.pdf
SAS-2: Expander Notification of Temporary Shutdown
(by: George O. Penokie)
T10/07-008r3   Uploaded: 2007/01/02   199722 bytes
ftp://ftp.t10.org/t10/document.07/07-008r3.pdf
SAS-2 Summary of FCC Radiated Emission Limits
(by: Barry Olawsky)
T10/07-011r0   Uploaded: 2007/01/03   66208 bytes
ftp://ftp.t10.org/t10/document.07/07-011r0.pdf
SMC-3 Clarification of reporting drive prevented media removal
(by: Curtis Ballard)
T10/07-015r0   Uploaded: 2007/01/01   51899 bytes
ftp://ftp.t10.org/t10/document.07/07-015r0.pdf
SSC-3 Additional controls for keyless copy
(by: Paul Entzel)
T10/07-016r0   Uploaded: 2007/01/02   28906 bytes
ftp://ftp.t10.org/t10/document.07/07-016r0.pdf
SMC-3 New Additional Sense Codes Usage
(by: Rod Wideman)
T10/07-018r0   Uploaded: 2007/01/03   99237 bytes
ftp://ftp.t10.org/t10/document.07/07-018r0.pdf
Minutes of SAS PHY Working Group conference call January 4, 2007
(by: Alvin Cox)
T10/07-019r0   Uploaded: 2007/01/04   23327 bytes
ftp://ftp.t10.org/t10/document.07/07-019r0.pdf
Agenda: ADI Meeting (15 January 2007)
(by: Michael Banther)
T10/07-020r0   Uploaded: 2007/01/05   9263 bytes
ftp://ftp.t10.org/t10/document.07/07-020r0.pdf
MANAGEMENT PROTOCOL IN command field name fixup
(by: Ralph O. Weber)
T10/07-022r0   Uploaded: 2007/01/06   31587 bytes
ftp://ftp.t10.org/t10/document.07/07-022r0.pdf
Working Drafts
--------------
Automation/Drive Interface - Commands - 2 (ADC-2)
(Editor: Paul Entzel)
 Rev: 07b      Uploaded: 2007/01/05   727469 bytes
ftp://ftp.t10.org/t10/drafts/adc2/adc2r07b.pdf
(Report generated on 2007/01/07 at 00:03:36)
*
* 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  Mon Jan  8 05:03:02 2007
From: roweber at IEEE.org (Ralph Weber)
Date: Mon, 08 Jan 2007 07:03:02 -0600
Subject: SPC-4 R08 uploaded
Message-ID: <mailman.16.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I hope nobody was holding their breath!
SPC-4 R08 containing all the changes approved in November
plus one approved in September has been uploaded as:
http://www.t10.org/ftp/t10/drafts/spc4/spc4r08.pdf
Enjoy,
.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  Mon Jan  8 05:03:02 2007
From: roweber at IEEE.org (Ralph Weber)
Date: Mon, 08 Jan 2007 07:03:02 -0600
Subject: SPC-4 R08 uploaded
Message-ID: <mailman.17.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at IEEE.org>
*
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I hope nobody was holding their breath!
SPC-4 R08 containing all the changes approved in November
plus one approved in September has been uploaded as:
http://www.t10.org/ftp/t10/drafts/spc4/spc4r08.pdf
Enjoy,
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 keiji_katata at post.pioneer.co.jp  Tue Jan  9 02:20:01 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 9 Jan 2007 19:20:01 +0900
Subject: Agenda proposal posted
Message-ID: <mailman.18.1441607320.22512.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 Agenda proposal and Load bit proposal.
Please pick them up from ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan07
I think the Load bit can be opposite setting as follows.
No-Load bit if set to 1 indicates that Logical Unit does not support medium
load
capability. When Logical unit reports 2-3A-0x MEDIUM NOT PRESENT, manual
intervention is required.
No-Load bit if set to 0 indicates that Logical Unit may support medium load
capability.
This description is compatible with the current situation.
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 Alvin.Cox at seagate.com  Tue Jan  9 08:02:46 2007
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Tue, 9 Jan 2007 10:02:46 -0600
Subject: SAS PHY agenda
Message-ID: <mailman.19.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701091_f.htm">HTML-formatted message</A>

06-515 (cleaned-up version of 06-324) SAS-2 Modifications to the SAS Speed 
Negotiation is the only item that I see far enough along to vote for 
recommendation to the plenary during next week's PHY working group. Please 
review and be prepared to vote on this proposal during the working group 
on 1/16/07. If there are any areas of concern, please contact Steve Finch 
and myself (prior to the meeting if possible) so that these can be 
addressed. Steve can be contacted at steve.finch at st.com.
I will post an updated agenda for the PHY working group after this week's 
conference call. Since 06-515 was virtually complete at the November 
meeting, I do not plan to spend time for review unless there are any 
issues that need to be addressed. The proposal may be reached through the 
link below.
http://www.t10.org/ftp/t10/document.06/06-515r0.pdf
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From matt.ball at quantum.com  Tue Jan  9 13:51:16 2007
From: matt.ball at quantum.com (Matt Ball)
Date: Tue, 9 Jan 2007 14:51:16 -0700
Subject: New Meeting: IEEE SISWG Key Management
Message-ID: <mailman.20.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701092_f.htm">HTML-formatted message</A>

Hi All,
For those interested, there will be an open IEEE SISWG Key Management
meeting on Tuesday from 9-noon in Ballroom C (to replace the cancelled
FCP meeting).  For more information, see:
SISWG Homepage: <http://ieee-p1619.wetpaint.com/&gt;
SISWG Meetings: <http://ieee-p1619.wetpaint.com/page/Upcoming+Meetings&gt;
Thanks,
Matt Ball
Quantum Corp.
4001 Discovery Drive Suite 1100
Boulder, CO 80303
720-406-5766


From Elliott at hp.com  Wed Jan 10 06:40:02 2007
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 10 Jan 2007 08:40:02 -0600
Subject: SAS-2 Transport Layer Retries
Message-ID: <mailman.21.1441607320.22512.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0701100_smime.p7s">smime.p7s</A>

Based on problems uncovered while implementing SAS-1.1 Transport
Layer Retries via the Protocol-Specific Logical Unit mode page, 
I've posted a new proposal 07-027r0 that defines a new method for 
enabling and disabling that feature - a field in the frame header 
of the COMMAND and TASK frames.
The proposal also adds a Protocol-Specific VPD page to SPC-4.
If you're interested in SAS tape drives, HBA firmware/drivers, or
software that accesses tape drives, please review this proposal.
(see http://www.t10.org/new.htm)
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


From Gary.Franco at emulex.com  Wed Jan 10 13:56:41 2007
From: Gary.Franco at emulex.com (Gary.Franco at emulex.com)
Date: Wed, 10 Jan 2007 13:56:41 -0800
Subject: Question regarding SCSI ATA Passthrough byte ordering
Message-ID: <mailman.22.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701101_f.htm">HTML-formatted message</A>

All,
Have a question with regard to byte ordering in the host for data
destined to be transmitted or received from a SATA device using SAT.
Should the data while it exists in the application client buffer be in
network byte order (or big endian if you prefer to think of it that way)
or should it be in the target devices byte ordering.
__________________________________
Gary Franco Consultant Engineer 
Emulex Network Systems 
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax 
720-652-6387 Longmont Colorado Office 
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote 
The mind is like a parachute. It doesn't work unless it's open.
-Unknown


From Alvin.Cox at seagate.com  Wed Jan 10 14:07:05 2007
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 10 Jan 2007 16:07:05 -0600
Subject: Reminder, SAS PHY call Jan 11,2007, 10 am CST
Message-ID: <mailman.23.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701102_f.htm">HTML-formatted message</A>

PARTICIPANT INFORMATION: 
Toll Free Dial in Number: (866) 279-4742 
International Access/Caller Paid Dial In Number: (309) 229-0118 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Agenda: 
1. Comments on 06-515.
http://www.t10.org/ftp/t10/document.06/06-515r0.pdf
2. Status on previous actions: 
a. Barry will make some measurements to determine if the low frequency 
issues are being captured. 
b. Barry to propose a set of loss values for a zero length test load. 
3. Continue discussion of use of mode and pk-to-pk to measure de-emphasis. 
Mode defined in 07-010r0 
Reference proposals/documents: 
http://www.t10.org/ftp/t10/document.07/07-010r0.pdf
http://www.t10.org/ftp/t10/document.07/07-001r1.pdf
http://www.t10.org/ftp/t10/document.06/06-496r2.pdf
Concern that both positive and negative values need to be taken rather 
than just doubling one side.
The test pattern needs to be defined.
Timing location for pk-to-pk and mode measurements.
Mike to update 07-001 to include actual measurements and indication of how 
calculate with both positive and negative traces.
Kevin Witt to also update his proposal with a mode measurement rather than 
small window intervals.
Bryan Kantack and Alvin Cox to write a description of the mode value for 
the specification based on the decided-upon measurement method.
4. Review of Proposed 6G SAS Phy Specs for EMI Reduction [Jenkins] 
Updated:
http://www.t10.org/ftp/t10/document.07/07-007r2.pdf, and 
http://www.t10.org/ftp/t10/document.07/07-007r2.ppt
5. New items.
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From roger_cummings at symantec.com  Wed Jan 10 17:17:17 2007
From: roger_cummings at symantec.com (Roger Cummings)
Date: Wed, 10 Jan 2007 20:17:17 -0500
Subject: Reception & Weather Info for next week's T10 meetings
Message-ID: <mailman.24.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701103_f.htm">HTML-formatted message</A>

Folks,
Symantec will be pleased to host a reception during next week's T10
meetings at the Marriott Orlando Lake Mary hotel. The reception will be
held from 7 to 9pm on Wednesday in Ballroom FGH at the hotel, and all
attendees and spouses are welcome. There will be a dinner buffet with
two entrees, salad and dessert, and there will also be a carvery. There
will be a bar at the reception but it will be a CASH bar. My apologies
for this, but when I was setting up the arrangements for this hosting in
late 2005 our merger was still being worked out, and I was told there
was some "legal" impediments to serving alcohol at a company function.
The fact that this way of doing things allows me to be lazy and not have
to count attendees or issue drinks tickets has nothing whatsoever to do
with it. :-))
Also, a quick word about the weather. Like many places, Orlando has been
having weird weather lately, and for example last weekend the
temperature got up to 85 degrees F with fairly high humidity - most
unusual here for this time of year. In the last few days, the weather
has been more typical - high near 70, low humidity & sunny. For next
week the forecast is generally good and sunny, with daytime highs near
80 and overnights lows near 60 Sunday and Monday, and thereafter highs
of 60 and overnight lows near 50. There is a chance of isolated
thunderstorms on Tuesday.
I will send another message on Friday with latest information about road
construction & driving directions.
Regards,
Roger Cummings
SYMANTEC
roger_cummings at symantec.com


From MOverby at nvidia.com  Wed Jan 10 17:31:31 2007
From: MOverby at nvidia.com (Mark Overby)
Date: Wed, 10 Jan 2007 17:31:31 -0800
Subject: Question regarding SCSI ATA Passthrough byte ordering
Message-ID: <mailman.25.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701104_f.htm">HTML-formatted message</A>

The buffer is expected to be in the order necessary for the underlying
bus / transport.
Let me be a little more detailed. If your SATL is in S/W on a Intel
based host, then you would expect the CDB (SRB on Windows) to be in the
standard buffer format for the processor.
However, if the SATL is in HW on a SAS bus, then you would transmit the
buffer in the manner required by the underlying transport.
I believe this to be the original intent. 
Hope that helps.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gary.Franco at emulex.com
Sent: Wednesday, January 10, 2007 1:57 PM
To: t10 at t10.org
Subject: Question regarding SCSI ATA Passthrough byte ordering
All,
Have a question with regard to byte ordering in the host for data
destined to be transmitted or received from a SATA device using SAT.
Should the data while it exists in the application client buffer be in
network byte order (or big endian if you prefer to think of it that way)
or should it be in the target devices byte ordering.
__________________________________
Gary Franco Consultant Engineer
Emulex Network Systems
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax 
720-652-6387 Longmont Colorado Office
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote
The mind is like a parachute. It doesn't work unless it's open.
-Unknown
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------


From michael.banther at hp.com  Thu Jan 11 09:31:44 2007
From: michael.banther at hp.com (Banther, Michael)
Date: Thu, 11 Jan 2007 17:31:44 -0000
Subject: CAP security discussions
Message-ID: <mailman.26.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701110_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0701110_banther_michael.vcf">banther_michael.vcf</A>

Hi George,
When do you intend to have the security-related discussions in CAP?
We're trying to coordinate coverage and make sure that the security
experts that normally attend SSC-3 don't miss out.
Regards,
Michael Banther
Hewlett-Packard Ltd.
+44 117 312 9503


From keiji_katata at post.pioneer.co.jp  Wed Jan 10 23:40:56 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 11 Jan 2007 16:40:56 +0900
Subject: Agenda proposal posted
Message-ID: <mailman.27.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi Ai san and all,
The date 15-17 is wrong. Correct date is 15-16.
"Drive Speed Detection commands" is just question from Garrett Jacobson.
Best regards,
Keiji Katata
PIONEER CORP.
keiji_katata at post.pioneer.co.jp@avc-pioneer.com on 2007/01/09 19:20:01
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
cc:    "T10" <T10 at t10.org>
bcc:
$B7oL>(B:  Agenda proposal posted
Hello all,
I posted Agenda proposal and Load bit proposal.
Please pick them up from ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan07
I think the Load bit can be opposite setting as follows.
No-Load bit if set to 1 indicates that Logical Unit does not support medium
load
capability. When Logical unit reports 2-3A-0x MEDIUM NOT PRESENT, manual
intervention is required.
No-Load bit if set to 0 indicates that Logical Unit may support medium load
capability.
This description is compatible with the current situation.
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 gop at us.ibm.com  Thu Jan 11 11:07:34 2007
From: gop at us.ibm.com (George Penokie)
Date: Thu, 11 Jan 2007 13:07:34 -0600
Subject: CAP security discussions
Message-ID: <mailman.28.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701112_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0701112_banther_michael.vcf">banther_michael.vcf</A>

Michael,
I looks like we will start security in CAP first thing on Wednesday.
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
"Banther, Michael" <michael.banther at hp.com> 
01/11/2007 11:31 AM
To
George Penokie/Rochester/IBM at IBMUS
cc
<t10 at t10.org>
Subject
CAP security discussions
Hi George,
When do you intend to have the security-related discussions in CAP?  We're 
trying to coordinate coverage and make sure that the security experts that 
normally attend SSC-3 don't miss out.
Regards,
Michael Banther
Hewlett-Packard Ltd.
+44 117 312 9503


From Shawn.Authement at texmemsys.com  Thu Jan 11 13:39:49 2007
From: Shawn.Authement at texmemsys.com (Shawn Authement)
Date: Thu, 11 Jan 2007 15:39:49 -0600
Subject: Persistent Reserve Out with TYPE field set to not implemented type
Message-ID: <mailman.29.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Shawn Authement <Shawn.Authement at texmemsys.com>
*
Dear Sirs,
SPC-3, 6.12.1 "PERSISTENT RESERVE OUT command introduction" states,
"The SCOPE and TYPE fields are defined in 6.11.3.3 and 6.11.3.4.  If a 
SCOPE field specifies a scope that is not implemented, the command shall 
be terminated with CHECK CONDITION status, with the sense key set to 
ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD IN CDB"
However, it does not mention what action is to be taken if the TYPE 
field specifies a type that is not implemented.  Is this also rejected 
with CHECK CONDITION status, sense key ILLEGAL REQUEST, and additional 
sense code INVALID FIELD IN CDB?
I searched the list archives and found this exact question posted 
(http://www.t10.org/ftp/t10/t10r/2003/r0304100.htm "subject:PERSISTENT 
RESERVE OUT with bad TYPE") , but I could not locate a response to that 
question.
Thank you for your time.
-- 
Shawn Authement
Software Engineer
Texas Memory Systems, Inc.
Shawn.Authement at texmemsys.com
ph: 713.266.3200
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From larry.hofer at mcdata.com  Thu Jan 11 15:10:33 2007
From: larry.hofer at mcdata.com (Larry Hofer)
Date: Thu, 11 Jan 2007 16:10:33 -0700
Subject: CAP security discussions
Message-ID: <mailman.30.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701114_f.htm">HTML-formatted message</A>

Hi George,
I was assuming it would be in the Tuesday afternoon session and it would
be coordinated with SSC security item schedule on the same day to
minimize time for those interested in security. 
Any chance of doing it Tuesday instead?
Larry
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of George
Penokie
Sent: Thursday, January 11, 2007 12:08 PM
To: Banther, Michael
Cc: t10 at t10.org
Subject: Re: CAP security discussions
Michael, 
I looks like we will start security in CAP first thing on Wednesday. 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208 
"Banther, Michael" <michael.banther at hp.com> 
01/11/2007 11:31 AM 
To
George Penokie/Rochester/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
CAP security discussions
Hi George, 
When do you intend to have the security-related discussions in CAP?
We're trying to coordinate coverage and make sure that the security
experts that normally attend SSC-3 don't miss out. 
Regards, 
Michael Banther 
Hewlett-Packard Ltd. 
+44 117 312 9503 
SPECIAL NOTICE
All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
hereby notified that you must not read this transmission and that disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.
Anyone who receives confidential and privileged information in error should
notify us immediately by phone and mail the original message to us at
the above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions apply to that


From gop at us.ibm.com  Thu Jan 11 15:19:23 2007
From: gop at us.ibm.com (George Penokie)
Date: Thu, 11 Jan 2007 17:19:23 -0600
Subject: CAP security discussions
Message-ID: <mailman.31.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701115_f.htm">HTML-formatted message</A>

Larry,
I was informed by the chair of the SSC group that their meeting would run 
all day. So to avoid overlapping security discussions I agreed to do the 
CAP security on Wednesday.
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
"Larry Hofer" <larry.hofer at mcdata.com> 
01/11/2007 05:10 PM
To
George Penokie/Rochester/IBM at IBMUS, "Banther, Michael" 
<michael.banther at hp.com>
cc
<t10 at t10.org>, "Larry Hofer" <larry.hofer at mcdata.com>
Subject
RE: CAP security discussions
Hi George,
I was assuming it would be in the Tuesday afternoon session and it would 
be coordinated with SSC security item schedule on the same day to minimize 
time for those interested in security. 
Any chance of doing it Tuesday instead?
Larry
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of George 
Penokie
Sent: Thursday, January 11, 2007 12:08 PM
To: Banther, Michael
Cc: t10 at t10.org
Subject: Re: CAP security discussions
Michael, 
I looks like we will start security in CAP first thing on Wednesday. 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208 
"Banther, Michael" <michael.banther at hp.com> 
01/11/2007 11:31 AM 
To
George Penokie/Rochester/IBM at IBMUS 
cc
<t10 at t10.org> 
Subject
CAP security discussions
Hi George, 
When do you intend to have the security-related discussions in CAP?  We're 
trying to coordinate coverage and make sure that the security experts that 
normally attend SSC-3 don't miss out. 
Regards, 
Michael Banther 
Hewlett-Packard Ltd. 
+44 117 312 9503 
SPECIAL NOTICE
All information transmitted hereby is intended only for the use of the
addressee(s) named above and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader
of this message is not the intended recipient(s) or the employee or agent
responsible for delivering the message to the intended recipient, you are
hereby notified that you must not read this transmission and that 
disclosure,
copying, printing, distribution or use of any of the information contained
in or attached to this transmission is STRICTLY PROHIBITED.
Anyone who receives confidential and privileged information in error 
should
notify us immediately by phone and mail the original message to us at
the above address and destroy all copies. To the extent any portion of 
this
communication contains public information, no such restrictions apply to 
that
information. (gate04)


From curtis.ballard at hp.com  Thu Jan 11 21:08:19 2007
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Fri, 12 Jan 2007 00:08:19 -0500
Subject: SMC3 Report Element Information 06-272r1 posted
Message-ID: <mailman.32.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
Sorry for the late posting but I finally have the latest draft of the
Report Element Information for SMC-3 proposal posted.
http://www.t10.org/ftp/t10/document.06/06-272r1.pdf
The primary change is the move to a 16 byte CDB as discussed in the
September meetings.
Curtis Ballard
*
* 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 Jan 12 04:51:54 2007
From: roweber at IEEE.org (Ralph Weber)
Date: Fri, 12 Jan 2007 06:51:54 -0600
Subject: Persistent Reserve Out with TYPE field set to not implemented
 type
Message-ID: <mailman.33.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Clearly, somebody was paranoid about testing the scope.
The following SPC-4 text (from 4.3.1 - CDB usage and structure)
also applies and this requirement covers both scope and type.
"If a logical unit receives a reserved CDB code value in a
field other than the OPERATION CODE field, then the logical
unit shall terminate the command with CHECK CONDITION status,
with the sense key set to ILLEGAL REQUEST, and the additional
sense code set to INVALID FIELD IN CDB."
No doubt, some wag has just made a note to expunge the 6.12.1
text cited below from SPC-4 during letter ballot since it is
clearly redundant.
All the best,
.Ralph
Shawn Authement wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Shawn Authement <Shawn.Authement at texmemsys.com>
> *
> Dear Sirs,
>
> SPC-3, 6.12.1 "PERSISTENT RESERVE OUT command introduction" states,
> "The SCOPE and TYPE fields are defined in 6.11.3.3 and 6.11.3.4.  If a 
> SCOPE field specifies a scope that is not implemented, the command 
> shall be terminated with CHECK CONDITION status, with the sense key 
> set to ILLEGAL REQUEST, and the additional sense code set to INVALID 
> FIELD IN CDB"
>
> However, it does not mention what action is to be taken if the TYPE 
> field specifies a type that is not implemented.  Is this also rejected 
> with CHECK CONDITION status, sense key ILLEGAL REQUEST, and additional 
> sense code INVALID FIELD IN CDB?
>
> I searched the list archives and found this exact question posted 
> (http://www.t10.org/ftp/t10/t10r/2003/r0304100.htm "subject:PERSISTENT 
> RESERVE OUT with bad TYPE") , but I could not locate a response to 
> that question.
>
> Thank you for your time.
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roger_cummings at symantec.com  Fri Jan 12 05:02:07 2007
From: roger_cummings at symantec.com (Roger Cummings)
Date: Fri, 12 Jan 2007 08:02:07 -0500
Subject: Driving Directions for next week's T10 meetings
Message-ID: <mailman.34.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701121_f.htm">HTML-formatted message</A>

Folks,
Here's the latest information on driving directions to the hotel for
next week's T10 meeting.
All of the links to directions given in the meeting announcement,
namely:
Directions from Orlando Airport (MCO): http://tinyurl.com/n7sm9
Directions from Daytona Beach (DAB): http://tinyurl.com/guw56
Directions from Sanford (SFB): http://tinyurl.com/n9ms7
are still good. Note that the route from Orlando Airport has currently
changed to use the SR-417 Greeneway and avoid downtown Orlando, and now
involves paying three tolls - two of 50c each and one of $2. There are
exact change lanes at the first two toll booths, so bring some quarters!
Note that the next-to last step of the directions from MCO & DAB is
incorrect - it is no longer necessary to make a U-turn on International
Parkway at Heathrow Park Lane - you can instead take the 2nd left on
International Parkway directly into the hotel complex.
TOLLS
See above, and note that if you're following other directions from
Orlando Airport that go via SR-408 and I-4 there's a 75c toll there too!
TRAFFIC INFORMATION
There's a good real time travel & traffic reporting system available by
calling 511 on your mobile phone, or at:
http://www.fl511.com/default.asp?area=FL_Central&display=critical
MAP
If you'd like a good single sheet map of the major roads in Central
Florida (including toll booths), please see:
https://epass.oocea.com/mapsandtravelinfo/maps/maps_centralflaexpressway
.shtml
On this map the hotel is located near the top center of the map close to
CR 46A just west of the junction with I-4.
See you all on Monday.
Regards,
Roger Cummings
SYMANTEC
roger_cummings at symantec.com


From michael.banther at hp.com  Fri Jan 12 08:28:30 2007
From: michael.banther at hp.com (Banther, Michael)
Date: Fri, 12 Jan 2007 16:28:30 -0000
Subject: Request for ADI-2 secretary and SMC-3 chairperson in May, 2007
Message-ID: <mailman.35.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701122_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0701122_banther_michael.vcf">banther_michael.vcf</A>

I will not attend the May, 2007 T10 week.  I'm looking for volunteers to
take my roles of secretary in the ADI-2 working group and chairperson in
the SMC-3 working group.  Please contact me if you have an interest.
Regards,
Michael Banther
Hewlett-Packard Ltd.
+44 117 312 9503


From lohmeyer at t10.org  Sat Jan 13 23:03:00 2007
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 14 Jan 2007 00:03:00 -0700
Subject: Recent T10 documents uploaded since 2007/01/07
Message-ID: <mailman.36.1441607320.22512.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 Element Information
(by: Curtis Ballard)
T10/06-272r1   Uploaded: 2007/01/11   191100 bytes
ftp://ftp.t10.org/t10/document.06/06-272r1.pdf
SAS2: ST_TTS retransmitted DATA frames
(by: Robert Sheffield)
T10/06-371r1   Uploaded: 2007/01/12   68679 bytes
ftp://ftp.t10.org/t10/document.06/06-371r1.jpg
SAS2: ST_TTS retransmitted DATA frames
(by: Robert Sheffield)
T10/06-371r1   Uploaded: 2007/01/12   55614 bytes
ftp://ftp.t10.org/t10/document.06/06-371r1.pdf
On-disk bitmap support
(by: Roger Cummings)
T10/06-393r2   Uploaded: 2007/01/12   228811 bytes
ftp://ftp.t10.org/t10/document.06/06-393r2.pdf
SMC-3: Diagnostics Data log page
(by: Kevin Marks)
T10/06-395r2   Uploaded: 2007/01/13   69487 bytes
ftp://ftp.t10.org/t10/document.06/06-395r2.pdf
SAS-2: Initiator handling of retransmit read DATA frames
(by: Vicky Duerk/Bob Sheffield)
T10/06-467r1   Uploaded: 2007/01/09   36757 bytes
ftp://ftp.t10.org/t10/document.06/06-467r1.pdf
SAS-2: Transport layer read data flowchart
(by: George O. Penokie)
T10/06-470r3   Uploaded: 2007/01/12   121970 bytes
ftp://ftp.t10.org/t10/document.06/06-470r3.pdf
SAS-2 Change to phy reset sequence 10ms rule
(by: Brian Day)
T10/06-471r1   Uploaded: 2007/01/12   68708 bytes
ftp://ftp.t10.org/t10/document.06/06-471r1.pdf
SAS-2 SPC-4 DISCOVER response Attached Device Name for SATA
(by: Rob Elliott)
T10/06-476r1   Uploaded: 2007/01/11   98720 bytes
ftp://ftp.t10.org/t10/document.06/06-476r1.pdf
Proposal for 6G SAS Phy Specification
(by: Michael Jenkins)
T10/07-001r1   Uploaded: 2007/01/09   180934 bytes
ftp://ftp.t10.org/t10/document.07/07-001r1.pdf
Proposed 6G SAS Phy Specs for EMI Reduction
(by: Michael Jenkins)
T10/07-007r2   Uploaded: 2007/01/09   83245 bytes
ftp://ftp.t10.org/t10/document.07/07-007r2.pdf
Proposed 6G SAS Phy Specs for EMI Reduction
(by: Michael Jenkins)
T10/07-007r2   Uploaded: 2007/01/09   152576 bytes
ftp://ftp.t10.org/t10/document.07/07-007r2.ppt
SAS-2 Transmitter/Receiver S-Parameter Measurements
(by: Barry Olawsky)
T10/07-012r0   Uploaded: 2007/01/11   273678 bytes
ftp://ftp.t10.org/t10/document.07/07-012r0.pdf
Secure LU Access
(by: George O. Penokie)
T10/07-023r0   Uploaded: 2007/01/08   578770 bytes
ftp://ftp.t10.org/t10/document.07/07-023r0.pdf
Secure LU Access
(by: George O. Penokie)
T10/07-023r1   Uploaded: 2007/01/09   228363 bytes
ftp://ftp.t10.org/t10/document.07/07-023r1.pdf
SMC-3 Medium transport element subclause correction
(by: Rod Wideman)
T10/07-024r0   Uploaded: 2007/01/08   75435 bytes
ftp://ftp.t10.org/t10/document.07/07-024r0.pdf
ADT-2 Negotiable Time-Outs
(by: Michael Banther)
T10/07-025r0   Uploaded: 2007/01/09   111258 bytes
ftp://ftp.t10.org/t10/document.07/07-025r0.pdf
ADT-2 Negotiable Time-Outs
(by: Michael Banther)
T10/07-025r1   Uploaded: 2007/01/10   108552 bytes
ftp://ftp.t10.org/t10/document.07/07-025r1.pdf
T11 Liaison Report, December 2006
(by: Robert Snively)
T10/07-026r0   Uploaded: 2007/01/09   14114 bytes
ftp://ftp.t10.org/t10/document.07/07-026r0.pdf
SAS-2 SPC-4 Enabling and disabling Transport Layer Retries
(by: Chris Martin and Rob Elliott)
T10/07-027r0   Uploaded: 2007/01/09   104645 bytes
ftp://ftp.t10.org/t10/document.07/07-027r0.pdf
SAS-2 Address resolved zoning
(by: Tim Symons)
T10/07-028r0   Uploaded: 2007/01/12   104341 bytes
ftp://ftp.t10.org/t10/document.07/07-028r0.pdf
SPC-4: Encapsulated SCSI Commands
(by: Ralph O. Weber)
T10/07-029r0   Uploaded: 2007/01/10   41905 bytes
ftp://ftp.t10.org/t10/document.07/07-029r0.pdf
Minutes of SAS PHY Working Group conference call January 11, 2007
(by: Alvin Cox)
T10/07-030r0   Uploaded: 2007/01/11   21973 bytes
ftp://ftp.t10.org/t10/document.07/07-030r0.pdf
SAS-2 Common Mode Generation Specification
(by: Kevin Witt & Mabuhbal Bari)
T10/07-037r0   Uploaded: 2007/01/12   1882265 bytes
ftp://ftp.t10.org/t10/document.07/07-037r0.pdf
Working Drafts
--------------
SCSI Primary Commands - 4 (SPC-4)
(Editor: Ralph Weber)
 Rev: 08       Uploaded: 2007/01/07   4018203 bytes
ftp://ftp.t10.org/t10/drafts/spc4/spc4r08.pdf
(Report generated on 2007/01/14 at 00:02:58)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From James.C.Hatfield at seagate.com  Tue Jan 16 10:38:57 2007
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Tue, 16 Jan 2007 11:38:57 -0700
Subject: 06-250r0 	SAT-2: Application Client Log Page Translation 
Message-ID: <mailman.37.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
re: 06-250r0	  SAT-2: Application Client Log Page Translation
Please make note in this proposal that
1) each ATA 'host vendor specific' log address contains 16 (x10) blocks of
512-bytes each
2) not all of these addresses are available for SAT use because some hosts
have allocated
      some of all for other uses already.
---------------- ATA8-ACS, rev 3f ------------------
A.8 Host Vendor Specific Logs
The logs at log addresses 80-9Fh (Host Vendor Specific addresses) shall
each be defined as sixteen 512-byte
blocks of data. The content of the Host Vendor Specific log addresses shall
be common to both Smart Log
Commands and General Purpose Log Commands. This means that if the host
places data in a Host Vendor
Specific page using SMART WRITE LOG, and then issues a READ LOG EXT to the
same page, that the host
receives the same data that was originally stored by SMART WRITE LOG.
These host vendor specific logs may be used by the host to store any data
desired. If a host vendor specific log
has never been written by the host, when read the content of the log shall
be zeros.
---------------- ATA8-ACS, rev 3f ------------------
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From MOverby at nvidia.com  Tue Jan 16 11:55:07 2007
From: MOverby at nvidia.com (Mark Overby)
Date: Tue, 16 Jan 2007 11:55:07 -0800
Subject: Test e-mail, please ignore (diagnosing problem with spam filter)
Message-ID: <mailman.38.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701161_f.htm">HTML-formatted message</A>

Please disregard this as I'm trying to assist my IT department on why
some T10 messages aren't getting through.
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------


From lohmeyer at t10.org  Tue Jan 16 12:54:42 2007
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 16 Jan 2007 13:54:42 -0700
Subject: SAS Protocol WG Minutes Posted
Message-ID: <mailman.39.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The minutes of the January 15, 2007 SAS Protocol Working Group meeting are
available at:
   http://www.t10.org/ftp/t10/document.07/07-031r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Tue Jan 16 13:15:07 2007
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 16 Jan 2007 14:15:07 -0700
Subject: SAT WG Minutes Posted
Message-ID: <mailman.40.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The minutes of the January 16, 2007 SAT Working Group meeting are available
at:
   http://www.t10.org/ftp/t10/document.07/07-032r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Tue Jan 16 15:43:56 2007
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 16 Jan 2007 16:43:56 -0700
Subject: Call for volunteers to edit MMC-6
Message-ID: <mailman.41.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Since Bill McFerrin no longer has management support to act as technical
editor of MMC-6 nor chair the MMC working group meetings, I am looking for
volunteers to fill one or both of these roles.
Please contact me if you are interested or have any questions.
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From michael.banther at hp.com  Thu Jan 18 08:01:18 2007
From: michael.banther at hp.com (Banther, Michael)
Date: Thu, 18 Jan 2007 16:01:18 -0000
Subject: ADI-2 teleconference announcement
Message-ID: <mailman.42.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701180_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0701180_banther_michael.vcf">banther_michael.vcf</A>

This is  T10 meeting announcement.
The ADI-2 working group will hold an ad-hoc teleconference on 31 January
2007 beginning at 8:00 AM PST (11:00 AM EST; 16:00 GMT) and concluding
at 10:00 AM PST (1:00 PM EST; 18:00 GMT).  You can find the meeting
agenda, including contact details, in the T10 document archive with
document number 07-049r0.  If you wish to attend from a country not
listed in the contact details, please e-mail me at 
michael.banther at hp.com, and I will attempt to provide a local or toll
free telephone number.
Regards,
Michael Banther
Hewlett-Packard Company
Tel. +44 117 312 9503


From lohmeyer at t10.org  Thu Jan 18 11:38:02 2007
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 18 Jan 2007 12:38:02 -0700
Subject: CAP Minutes Posted
Message-ID: <mailman.43.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The minutes of the January 17, 2007 CAP Working Group meeting are available
at:
   http://www.t10.org/ftp/t10/document.07/07-033r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Thu Jan 18 21:18:09 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 19 Jan 2007 14:18:09 +0900
Subject: Call for volunteers to edit MMC-6
Message-ID: <mailman.44.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi John,
May I confirm this Call.
1. Qualification to be volunteer.
2. Issue of MMC-6
3. Description of job
1. Qualification
What is necessary to be a volunteer. What I thought is that a volunteer is
not
T10 member. But volunteer may help the modification of the document as a
volunteer. In T10, someone other than the volunteer who is T10 member may
explain the progress/result to T10.
2. Issue
The discussion of MMC-6 has been closed. Is it an editorial item? Is it a
technical item? Do you have a list of them?
3. Job
What a volunteer should do? If you have a list of issues, then a volunteer
may
check those items in the list, may understand the commented issue one by one,
then may make a proposal of the solution. Then What a volunteer should do?
Best regards,
Keiji Katata
PIONEER CORP.
John Lohmeyer <lohmeyer at t10.org>@t10.org on 2007/01/17 08:43:56
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B:  T10 Reflector <t10 at t10.org>
cc:
bcc:
$B7oL>(B:  Call for volunteers to edit MMC-6
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Since Bill McFerrin no longer has management support to act as technical
editor
of MMC-6 nor chair the MMC working group meetings, I am looking for
volunteers
to fill one or both of these roles.
Please contact me if you are interested or have any questions.
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Fri Jan 19 00:06:43 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 19 Jan 2007 17:06:43 +0900
Subject: Call for volunteers to edit MMC-6
Message-ID: <mailman.45.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
I'm very sorry.
I misunderstood that you asked about MMC5.
But it is MMC6 that is new project.
So the question about this should be only "1. Qualification to be volunteer".
The answer may be "volunteer should be T10 member".
I'm very sorry that I mistake.
Best regards,
Keiji Katata
PIONEER CORP.
keiji_katata at post.pioneer.co.jp@t10.org on 2007/01/19 14:18:09
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B:  John Lohmeyer <lohmeyer at t10.org>
cc:    T10 Reflector <t10 at t10.org>
bcc:
$B7oL>(B:  Re: Call for volunteers to edit MMC-6
* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi John,
May I confirm this Call.
1. Qualification to be volunteer.
2. Issue of MMC-6
3. Description of job
1. Qualification
What is necessary to be a volunteer. What I thought is that a volunteer is
not
T10 member. But volunteer may help the modification of the document as a
volunteer. In T10, someone other than the volunteer who is T10 member may
explain the progress/result to T10.
2. Issue
The discussion of MMC-6 has been closed. Is it an editorial item? Is it a
technical item? Do you have a list of them?
3. Job
What a volunteer should do? If you have a list of issues, then a volunteer
may
check those items in the list, may understand the commented issue one by one,
then may make a proposal of the solution. Then What a volunteer should do?
Best regards,
Keiji Katata
PIONEER CORP.
John Lohmeyer <lohmeyer at t10.org>@t10.org on 2007/01/17 08:43:56
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B:  T10 Reflector <t10 at t10.org>
cc:
bcc:
$B7oL>(B:  Call for volunteers to edit MMC-6
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Since Bill McFerrin no longer has management support to act as technical
editor
of MMC-6 nor chair the MMC working group meetings, I am looking for
volunteers
to fill one or both of these roles.
Please contact me if you are interested or have any questions.
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Alvin.Cox at seagate.com  Fri Jan 19 06:47:08 2007
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Fri, 19 Jan 2007 08:47:08 -0600
Subject: PHY working group minutes posted
Message-ID: <mailman.46.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701191_f.htm">HTML-formatted message</A>

PHY working group minutes posted at:
http://www.t10.org/ftp/t10/document.07/07-043r0.pdf
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From lohmeyer at t10.org  Sat Jan 20 23:03:08 2007
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 21 Jan 2007 00:03:08 -0700
Subject: Recent T10 documents uploaded since 2007/01/14
Message-ID: <mailman.47.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
ADI:  Features for ADC-2 and ADT-2
(by: Paul Suhler)
T10/06-060r5   Uploaded: 2007/01/15   52084 bytes
ftp://ftp.t10.org/t10/document.06/06-060r5.pdf
SAT-2: Application Client Log Page Translation
(by: Mark Overby)
T10/06-250r0   Uploaded: 2007/01/15   78026 bytes
ftp://ftp.t10.org/t10/document.06/06-250r0.pdf
SAS-2 Address Resolved Configuration
(by: Steve Johnson)
T10/06-303r0   Uploaded: 2007/01/15   67424 bytes
ftp://ftp.t10.org/t10/document.06/06-303r0.pdf
SAS-2 Response to abandon-class OPEN_REJECT
(by: Rob Elliott)
T10/06-322r4   Uploaded: 2007/01/15   81041 bytes
ftp://ftp.t10.org/t10/document.06/06-322r4.pdf
SAM-4 Response Fence for protocol services
(by: Rob Elliott)
T10/06-341r1   Uploaded: 2007/01/16   80281 bytes
ftp://ftp.t10.org/t10/document.06/06-341r1.pdf
SPC-4 Read debug data proposal
(by: Gerald Houlder)
T10/06-362r2   Uploaded: 2007/01/15   141312 bytes
ftp://ftp.t10.org/t10/document.06/06-362r2.doc
SPC-4 Read debug data proposal
(by: Gerald Houlder)
T10/06-362r2   Uploaded: 2007/01/15   144778 bytes
ftp://ftp.t10.org/t10/document.06/06-362r2.pdf
SPC-4 Read debug data proposal
(by: Gerald Houlder)
T10/06-362r3   Uploaded: 2007/01/16   141824 bytes
ftp://ftp.t10.org/t10/document.06/06-362r3.doc
SPC-4 Read debug data proposal
(by: Gerald Houlder)
T10/06-362r3   Uploaded: 2007/01/17   146890 bytes
ftp://ftp.t10.org/t10/document.06/06-362r3.pdf
SSC-3 Using Public-Key Cryptography for Key Wrapping
(by: Gideon Avida)
T10/06-389r5   Uploaded: 2007/01/17   98599 bytes
ftp://ftp.t10.org/t10/document.06/06-389r5.pdf
SPC-4 Target Port Group disconnected state proposal
(by: Frederick Knight)
T10/06-390r2   Uploaded: 2007/01/16   157803 bytes
ftp://ftp.t10.org/t10/document.06/06-390r2.pdf
On-disk bitmap support, Rev 3
(by: Roger Cummings)
T10/06-393r3   Uploaded: 2007/01/16   228130 bytes
ftp://ftp.t10.org/t10/document.06/06-393r3.pdf
SSC-3 Encryption KAD Lengths and Nonces
(by: Paul Suhler)
T10/06-412r3   Uploaded: 2007/01/16   41114 bytes
ftp://ftp.t10.org/t10/document.06/06-412r3.pdf
SAS-2: SAM-4: Miscellaneous State Machine Fixes
(by: George O. Penokie)
T10/06-451r5   Uploaded: 2007/01/15   562960 bytes
ftp://ftp.t10.org/t10/document.06/06-451r5.pdf
SAS-2: SAM-4: Miscellaneous State Machine Fixes
(by: George O. Penokie)
T10/06-451r6   Uploaded: 2007/01/16   573519 bytes
ftp://ftp.t10.org/t10/document.06/06-451r6.pdf
ADC-2: NL-Port vs. LN-Port
(by: Kevin Butt)
T10/06-468r2   Uploaded: 2007/01/17   41504 bytes
ftp://ftp.t10.org/t10/document.06/06-468r2.pdf
SAS-2: Transport layer read data flowchart
(by: George O. Penokie)
T10/06-470r4   Uploaded: 2007/01/16   123555 bytes
ftp://ftp.t10.org/t10/document.06/06-470r4.pdf
SAS-2 Electrical Specification Proposal
(by: Kevin Witt)
T10/06-496r3   Uploaded: 2007/01/16   2181527 bytes
ftp://ftp.t10.org/t10/document.06/06-496r3.pdf
SAT-2: Work Items and Open Issues
(by: Mark Overby)
T10/06-497r2   Uploaded: 2007/01/15   16561 bytes
ftp://ftp.t10.org/t10/document.06/06-497r2.pdf
Minutes (Rev 1) of SMC Working Group - November 6, 2006
(by: Roger Cummings)
T10/06-498r1   Uploaded: 2007/01/16   37348 bytes
ftp://ftp.t10.org/t10/document.06/06-498r1.pdf
Minutes (rev 1) of SMC Conference Call - November 30, 2006
(by: Roger Cummings)
T10/07-003r1   Uploaded: 2007/01/16   27829 bytes
ftp://ftp.t10.org/t10/document.07/07-003r1.pdf
SAS-2 Zero-Length Test Load Characterization
(by: Barry Olawsky)
T10/07-013r0   Uploaded: 2007/01/16   79295 bytes
ftp://ftp.t10.org/t10/document.07/07-013r0.pdf
SNIA requested OSD changes
(by: Ralph O. Weber)
T10/07-014r1   Uploaded: 2007/01/17   72049 bytes
ftp://ftp.t10.org/t10/document.07/07-014r1.pdf
More Zone Groups
(by: Steve Johnson)
T10/07-017r0   Uploaded: 2007/01/14   117415 bytes
ftp://ftp.t10.org/t10/document.07/07-017r0.pdf
Minutes: ADI Meeting (15 January 2007)
(by: Michael Banther)
T10/07-021r0   Uploaded: 2007/01/18   44981 bytes
ftp://ftp.t10.org/t10/document.07/07-021r0.pdf
MANAGEMENT PROTOCOL IN command field name fixup
(by: Ralph O. Weber)
T10/07-022r1   Uploaded: 2007/01/17   33100 bytes
ftp://ftp.t10.org/t10/document.07/07-022r1.pdf
ADT-2 Negotiable Time-Outs
(by: Michael Banther)
T10/07-025r2   Uploaded: 2007/01/15   110881 bytes
ftp://ftp.t10.org/t10/document.07/07-025r2.pdf
Minutes of SAS Protocol Working Group - January 15, 2007
(by: Weber & Lohmeyer)
T10/07-031r0   Uploaded: 2007/01/16   48359 bytes
ftp://ftp.t10.org/t10/document.07/07-031r0.htm
Minutes of SAS Protocol Working Group - January 15, 2007
(by: Weber & Lohmeyer)
T10/07-031r0   Uploaded: 2007/01/16   122267 bytes
ftp://ftp.t10.org/t10/document.07/07-031r0.pdf
Minutes of SAT Working Group - January 16, 2007
(by: John Lohmeyer)
T10/07-032r0   Uploaded: 2007/01/16   28108 bytes
ftp://ftp.t10.org/t10/document.07/07-032r0.htm
Minutes of SAT Working Group - January 16, 2007
(by: John Lohmeyer)
T10/07-032r0   Uploaded: 2007/01/16   88579 bytes
ftp://ftp.t10.org/t10/document.07/07-032r0.pdf
Minutes of CAP Working Group - January 16-17, 2007
(by: Weber & Lohmeyer)
T10/07-033r0   Uploaded: 2007/01/18   42430 bytes
ftp://ftp.t10.org/t10/document.07/07-033r0.htm
Minutes of CAP Working Group - January 16-17, 2007
(by: Weber & Lohmeyer)
T10/07-033r0   Uploaded: 2007/01/18   118987 bytes
ftp://ftp.t10.org/t10/document.07/07-033r0.pdf
SMC-3: RES - Incomplete descriptors
(by: Kevin Butt)
T10/07-035r0   Uploaded: 2007/01/15   17758 bytes
ftp://ftp.t10.org/t10/document.07/07-035r0.pdf
Minutes: of SSC-3 Working Group - 16 Jan 2007
(by: Kevin Butt)
T10/07-036r0   Uploaded: 2007/01/16   74250 bytes
ftp://ftp.t10.org/t10/document.07/07-036r0.pdf
SAS-2 Expander Route Table (CONFIGURE ADDRESS RESOLVED)
(by: Steve Johnson)
T10/07-038r0   Uploaded: 2007/01/14   84749 bytes
ftp://ftp.t10.org/t10/document.07/07-038r0.pdf
SSC-3: Working Group Agenda - January 16, 2007
(by: David Peterson)
T10/07-040r0   Uploaded: 2007/01/15   11444 bytes
ftp://ftp.t10.org/t10/document.07/07-040r0.pdf
Minutes of SMC Working Group - January 15, 2007
(by: Roger Cummings)
T10/07-041r0   Uploaded: 2007/01/17   43735 bytes
ftp://ftp.t10.org/t10/document.07/07-041r0.pdf
ADI-2 Working Group Report to Plenary, January 2007
(by: Paul Suhler)
T10/07-042r0   Uploaded: 2007/01/15   16658 bytes
ftp://ftp.t10.org/t10/document.07/07-042r0.pdf
ADI-2 Working Group Report to Plenary, January 2007
(by: Paul Suhler)
T10/07-042r1   Uploaded: 2007/01/15   16748 bytes
ftp://ftp.t10.org/t10/document.07/07-042r1.pdf
Minutes of SAS PHY Working Group, January 16, 2007
(by: Alvin Cox)
T10/07-043r0   Uploaded: 2007/01/17   29880 bytes
ftp://ftp.t10.org/t10/document.07/07-043r0.pdf
IEEE Security in Storage Workgroup (P1619.x) Status Report to T10
(2007-01-16)
(by: Matthew Ball)
T10/07-044r0   Uploaded: 2007/01/16   16776 bytes
ftp://ftp.t10.org/t10/document.07/07-044r0.pdf
Type 1 Vs. 2
(by: Harvey Newman)
T10/07-045r0   Uploaded: 2007/01/16   1493597 bytes
ftp://ftp.t10.org/t10/document.07/07-045r0.pdf
SSC-3 Requested Recovery log page
(by: Michael Banther)
T10/07-046r0   Uploaded: 2007/01/17   94707 bytes
ftp://ftp.t10.org/t10/document.07/07-046r0.pdf
STA -T10 Liaison Report - January 18, 2007
(by: Marty Czekalski)
T10/07-047r0   Uploaded: 2007/01/17   184596 bytes
ftp://ftp.t10.org/t10/document.07/07-047r0.pdf
SMC-3 January, 2007 Plenary Report
(by: Michael Banther)
T10/07-048r0   Uploaded: 2007/01/18   16321 bytes
ftp://ftp.t10.org/t10/document.07/07-048r0.pdf
Agenda: ADI-2 Teleconference 31 January 2007
(by: Michael Banther)
T10/07-049r0   Uploaded: 2007/01/18   9252 bytes
ftp://ftp.t10.org/t10/document.07/07-049r0.pdf
SNIA Report to T10 January 2007
(by: Steven Wilson)
T10/07-051r0   Uploaded: 2007/01/18   63250 bytes
ftp://ftp.t10.org/t10/document.07/07-051r0.pdf
Agenda for T10 Meeting #78 (March 2007)
(by: John Lohmeyer)
T10/07-052r0   Uploaded: 2007/01/18   70295 bytes
ftp://ftp.t10.org/t10/document.07/07-052r0.pdf
T10 Project Summary - January 2007
(by: John Lohmeyer)
T10/07-053r0   Uploaded: 2007/01/18   34867 bytes
ftp://ftp.t10.org/t10/document.07/07-053r0.pdf
Jeopardy Letter for March 2007 meeting
(by: John Lohmeyer)
T10/07-054r0   Uploaded: 2007/01/18   0 bytes
ftp://ftp.t10.org/t10/document.07/07-054r0.pdf
Working Drafts
--------------
Automation/Drive Interface - Transport Protocol - 2 (ADT-2)
(Editor: Paul Entzel)
 Rev: 04       Uploaded: 2007/01/19   1092495 bytes
ftp://ftp.t10.org/t10/drafts/adt2/adt2r04.pdf
(Report generated on 2007/01/21 at 00:03:01)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Mon Jan 22 00:34:02 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 22 Jan 2007 17:34:02 +0900
Subject: February Fuji Meeting Host change
Message-ID: <mailman.48.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
Toshiba kindly hosts the February Fuji meeting.
The meeting date Feb. 14, 15 is not changed.
The more information will be announced from Toshiba later.
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 clyon at scsita.org  Mon Jan 22 10:40:49 2007
From: clyon at scsita.org (Chris Lyon)
Date: Mon, 22 Jan 2007 10:40:49 -0800
Subject: March T-10 meeting information
Message-ID: <mailman.49.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701221_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0701221_mar07mtgflyerc.doc">mar07mtgflyerc.doc</A>
Attachment #2: <A HREF="r0701221_mar07mtgflyerc-1.doc">mar07mtgflyerc-1.doc</A>
Formatted message: <A HREF="r0701221_f.htm">HTML-formatted message</A>

Dear STA and T-10 members,
Attached is the latest flyer with hotel information for the March  
meeting. Please note that the registration deadline is February 11th  
so register right away.
See you in Memphis!
Chris
???
-=-=-=-=-=-=- SCSI Trade Association -=-=-=-=-=-=-
Chris Lyon, CAE 			Tel. +1.425.286.1111
Executive Director			Fax +1.425.488.3646
18221 102nd Ave N.E.		  E-mail: Clyon at scsita.org
Bothell, WA 98011		       http://www.scsita.org
The SCSI Trade Association is managed by LoBue & Majdalany Management  
Group, an IAAMC Charter Accredited  
Firm._______________________________________________


From clyon at scsita.org  Mon Jan 22 10:40:49 2007
From: clyon at scsita.org (Chris Lyon)
Date: Mon, 22 Jan 2007 10:40:49 -0800
Subject: [STA Members] March T-10 meeting information
Message-ID: <mailman.50.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701222_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0701222_mar07mtgflyerc.doc">mar07mtgflyerc.doc</A>
Attachment #2: <A HREF="r0701222_mar07mtgflyerc-1.doc">mar07mtgflyerc-1.doc</A>
Formatted message: <A HREF="r0701222_f.htm">HTML-formatted message</A>

Dear STA and T-10 members,
Attached is the latest flyer with hotel information for the March  
meeting. Please note that the registration deadline is February 11th  
so register right away.
See you in Memphis!
Chris
???
-=-=-=-=-=-=- SCSI Trade Association -=-=-=-=-=-=-
Chris Lyon, CAE 			Tel. +1.425.286.1111
Executive Director			Fax +1.425.488.3646
18221 102nd Ave N.E.		  E-mail: Clyon at scsita.org
Bothell, WA 98011		       http://www.scsita.org
The SCSI Trade Association is managed by LoBue & Majdalany Management  
Group, an IAAMC Charter Accredited  
Firm._______________________________________________


From shunsuke.kimura at toshiba.co.jp  Mon Jan 22 20:05:07 2007
From: shunsuke.kimura at toshiba.co.jp (Shunsuke Kimura)
Date: Tue, 23 Jan 2007 13:05:07 +0900
Subject: February Mt.Fuji meeting announcement
Message-ID: <mailman.51.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Shunsuke Kimura <shunsuke.kimura at toshiba.co.jp>
*
Dear Mt.Fuji members,
The February Mt.Fuji meeting will be held as follows;
-----------------------------------------------------------------------------
------
1. Date & Time
	February 14 and 15 (Wednesday and Thursday)   10:00 am -  5:00 pm
2. Place
	Toshiba Headquaters Building 39th floor, Room 3919 (Available from
9:30)
	http://www.toshiba.co.jp/worldwide/about/overseas.html
	Seven minutes on foot through passage from Hamamatsucho Station,
	Yamanote Line or Keihin-Tohoku Line. (JR) 
3. Request for attendees
	Please inform me the attendants by "February 12 (Japan Time)".
	NOTE: ATTENDEE LIST is required for security reason and preparing
	the meeting facilities.
-----------------------------------------------------------------------------
------
Best Regards,
Shunsuke Kimura
Toshiba
*
* 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 Jan 23 13:04:24 2007
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 23 Jan 2007 14:04:24 -0700
Subject: T10 Plenary Minutes posted
Message-ID: <mailman.52.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft T10 minutes of the January 18, 2007 meeting are available at:
   http://www.t10.org/ftp/t10/document.07/07-034r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Alvin.Cox at seagate.com  Tue Jan 23 13:25:05 2007
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Tue, 23 Jan 2007 15:25:05 -0600
Subject: SAS PHY teleconference, 
Message-ID: <mailman.53.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701231_f.htm">HTML-formatted message</A>

Any additional agenda items for this week? Please contact me with any 
items.
I am in the process of drafting a first pass 6G PHY specification based 
largely on the proposals from Kevin Witt and Mike Jenkins for many of the 
numbers and format as well as incorporation of some aspects in the current 
1.5G and 3G specs. 
Other items needing consideration:
Tolerance for default transmitter de-emphasis.
Definition of TCTF better than just S21.
Jitter values.
Rise time/fall time.
So far for this week: 
1. 07-045r0, Type 1 Vs. 2 [Newman]
http://www.t10.org/ftp/t10/document.07/07-045r0.pdf
Next conference call January 25, 2007
Weekly teleconferences scheduled for Thursdays at 10 am CST: 
PARTICIPANT INFORMATION: 
Toll Free Dial in Number: (866) 279-4742 
International Access/Caller Paid Dial In Number: (309) 229-0118 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From clyon at scsita.org  Tue Jan 23 14:25:24 2007
From: clyon at scsita.org (Chris Lyon)
Date: Tue, 23 Jan 2007 14:25:24 -0800
Subject: [STA Members] March T-10 Hotel Rooms
Message-ID: <mailman.54.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701232_f.htm">HTML-formatted message</A>

Dear T-10 and STA members,
I have heard from a few of you that you have been told the room block  
is sold out for the March meetings.  I have contacted the Hotel and  
they stated that Sunday night room block was full which was stopping  
people from booking other nights. I had them add more rooms to Sunday  
so if you were planning on arriving Sunday we should have you covered  
now. The Hotel asked that they be given a couple of hours to update  
their system so please try again after 4:30 PST today. Here is the  
booking link again:
http://marriott.com/property/propertypage/memdt? 
groupCode=scsscsa&app=resvlink
Sorry for any confusion.
Chris Lyon
-=-=-=-=-=-=- SCSI Trade Association -=-=-=-=-=-=-
Chris Lyon, CAE 			Tel. +1.425.286.1111
Executive Director			Fax +1.425.488.3646
18221 102nd Ave N.E.		  E-mail: Clyon at scsita.org
Bothell, WA 98011		       http://www.scsita.org
The SCSI Trade Association is managed by LoBue & Majdalany Management  
Group, an IAAMC Charter Accredited  
Firm._______________________________________________


From craig at expertio.com  Tue Jan 23 14:24:22 2007
From: craig at expertio.com (Craig Stoops)
Date: Tue, 23 Jan 2007 14:24:22 -0800
Subject: SAS2 SNW-3 SP29:SAS_Train
Message-ID: <mailman.55.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701233_f.htm">HTML-formatted message</A>

Steve, Rob and other interested parties,
Per the latest 6Gb SNW-3 proposal pasted below, the TRAIN Completed message
is not defined in the document. Based on my read of other parts, I think
this should be "TRAIN Transmitted message" as the requirement per
6.7.4.2.3.3 is to send at least 1 TRAIN pattern and after achieving receiver
sync, then transition to sending TRAIN_DONE. 
6.8.4.12.4 Transition SP29:SAS_Train to SP30:SAS_TrainingDone
This transition shall occur if:
a) this state receives a TRAIN Completed message before the TLT timer
expires; and
b) dword synchronization is acquired.
Second point - becuase one end device may be capable of acheiving rx sync
faster than the other, it is possible (as seen by our modeling) for the
slower device to be in SP29 and before that device gains sync the faster
device starts sending TRAIN_DONE.
So it can not be a condition of SP29 -> SP30 to receive a TRAIN pattern, but
rather either TRAIN or a TRAIN_DONE pattern This is implied by aquiring
receiver synchronization.. Currently, as it is undefined, some people may
consider the TRAIN Completed message to be TRAIN Received messsage.
I think it should be further clarified, as I beleive was the original
intention, that both TRAIN and TRAIN_DONE serve to allow a receiver to gain
synchronization. If true, then the slow device will transition from SP29 to
SP30 when gaining rx sync even though it is receiving TRAIN_DONE and not
TRAIN.
Basically, in summary, rewording 6.8.4.12.4 to:
  This transition shall occur after:  
    a) Transmitting at least 1 complete TRAIN pattern (or said the spec way,
after having received at least one TRAIN Transmitted message)
   b) Receiver DWORD synchronization is acquired
Thoughts?
Craig Stoops
ExpertIO, Inc
www.expertio.com
805-428-0839


From clyon at scsita.org  Tue Jan 23 14:25:24 2007
From: clyon at scsita.org (Chris Lyon)
Date: Tue, 23 Jan 2007 14:25:24 -0800
Subject: March T-10 Hotel Rooms
Message-ID: <mailman.56.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701234_f.htm">HTML-formatted message</A>

Dear T-10 and STA members,
I have heard from a few of you that you have been told the room block  
is sold out for the March meetings.  I have contacted the Hotel and  
they stated that Sunday night room block was full which was stopping  
people from booking other nights. I had them add more rooms to Sunday  
so if you were planning on arriving Sunday we should have you covered  
now. The Hotel asked that they be given a couple of hours to update  
their system so please try again after 4:30 PST today. Here is the  
booking link again:
http://marriott.com/property/propertypage/memdt? 
groupCode=scsscsa&app=resvlink
Sorry for any confusion.
Chris Lyon
-=-=-=-=-=-=- SCSI Trade Association -=-=-=-=-=-=-
Chris Lyon, CAE 			Tel. +1.425.286.1111
Executive Director			Fax +1.425.488.3646
18221 102nd Ave N.E.		  E-mail: Clyon at scsita.org
Bothell, WA 98011		       http://www.scsita.org
The SCSI Trade Association is managed by LoBue & Majdalany Management  
Group, an IAAMC Charter Accredited  
Firm._______________________________________________


From plavarre at lexar.com  Tue Jan 23 16:16:23 2007
From: plavarre at lexar.com (Pat LaVarre)
Date: Tue, 23 Jan 2007 16:16:23 -0800
Subject: mask x07 or x03 defines Rsoc Cdb byte 2
Message-ID: <mailman.57.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <plavarre at lexar.com>
*
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>mask x07 or x03 defines Rsoc Cdb byte 2</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Spc4r08.pdf at p.231 discusses "REPORT SUPPORTED =
OPERATION CODES".&nbsp; It has an example CDB usage map that =
labeled as "the" CDB usage map of "REPORT SUPPORTED =
OPERATION CODES".<BR>
<BR>
A3h, 0Ch, 03h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is the =
example.<BR>
<BR>
A3h, 0Ch, 07h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is what I =
expected at first glance, since the REPORTING OPTION codes go in the =
three lsb's of byte 2 of the Cdb, and my mask 07h rather than the Pdf's =
03h in byte 2 would be a mask of three lsb's rather than two lsb's.<BR>
<BR>
Is 07h rather than 03h in byte 2 yes obviously what we meant to type, or =
have I misunderstood, or is something interesting happening here?<BR>
<BR>
Curiously yours,<BR>
</FONT>
</P>
</BODY>
</HTML>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From robert.l.sheffield at intel.com  Tue Jan 23 20:28:38 2007
From: robert.l.sheffield at intel.com (Sheffield, Robert L)
Date: Tue, 23 Jan 2007 21:28:38 -0700
Subject: mask x07 or x03 defines Rsoc Cdb byte 2
Message-ID: <mailman.58.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701236_f.htm">HTML-formatted message</A>

Wish I could provide an answer, but all I can do is pose two more
follow-on questions:
I notice that while the REPORTING OPTIONS field (lower 3 bits of byte-2
in the REPORT SUPPORTED OPERATION CODES command) is a 3-bit field, the
there are only 3 code values defined for this field (000b, 001b, and
010b - bit-2 is always zero), with code values 011b - 111b reserved. The
rules say, 
	"If the device server evaluates a bit in the CDB for the command
being queried, the usage map shall contain a one in the corresponding
bit position. If any bit representing part of a field is returned as
one, all bits for the field shall be returned as one. If the device
server ignores or treats as reserved a bit in the CDB for the command
being queried, the usage map shall contain a zero in the corresponding
bit position."
The first sentence says report three bits worth of "1". If one could
interpret the fact that the reserved code values cover all the values
where the high-order bit is set to 1, that the high order bit is
therefore reserved, then the rule in the second sentence might lead to
setting only the lower-order two bits to "1", and the high-order bit to
zero. But I don't think that's the intent, so I think you are correct,
7h is correct.
The other more interesting question is why isn't byte-2 equal to 87h
(rather than 07h). Does this mean that the device server in the example
treats the RCTD bit as reserved? Are device servers that support the
REPORT SUPPORTED OPERATION CODES command required to support an RCTD bit
set to one? If not, then presumably the device server could report
either 07h or 87h in byte-2 of the CDB usage map for the REPORT
SUPOPRTED OPERATION CODES CDB.
Either way - looks like something to fix in SPC-4.
Bob Sheffield
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pat
LaVarre
Sent: Tuesday, January 23, 2007 5:16 PM
To: T10 Reflector
Subject: mask x07 or x03 defines Rsoc Cdb byte 2
* From the T10 Reflector (t10 at t10.org), posted by: * "Pat LaVarre" * 
Spc4r08.pdf at p.231 discusses "REPORT SUPPORTED OPERATION CODES".  It
has an example CDB usage map that labeled as "the" CDB usage map of
"REPORT SUPPORTED OPERATION CODES".
A3h, 0Ch, 03h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is the
example.
A3h, 0Ch, 07h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is what I
expected at first glance, since the REPORTING OPTION codes go in the
three lsb's of byte 2 of the Cdb, and my mask 07h rather than the Pdf's
03h in byte 2 would be a mask of three lsb's rather than two lsb's.
Is 07h rather than 03h in byte 2 yes obviously what we meant to type, or
have I misunderstood, or is something interesting happening here?
Curiously yours,
* * 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 Jan 23 20:23:58 2007
From: roweber at ieee.org (Ralph Weber)
Date: Tue, 23 Jan 2007 22:23:58 -0600
Subject: mask x07 or x03 defines Rsoc Cdb byte 2
Message-ID: <mailman.59.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701237_f.htm">HTML-formatted message</A>

Pat,
My review of SPC-4 r08 indicates that your comment is
almost right.
CDB byte 2 does contain a 3-bit field in the low-order
bits and that makes your proposed change from 03h to 07h
correct ... as far as it goes.
However, SPC-4 r08 adds the command timeouts reporting
option to the REPORT SUPPORTED OPERATION CODES command.
This new feature defines bit 7 of byte 2 as the RCTD
(Return Command Timeouts Descriptor) bit. When this
change is added to the issue which you have reported
the cited byte needs to change from 03h to 87h.
Unless I hear objections, I will made this change
in SPC-4 r09.
All the best,
.Ralph
Pat LaVarre wrote:
> * From the T10 Reflector (t10 at t10.org), posted by: * "Pat LaVarre" *
>
> Spc4r08.pdf at p.231 discusses "REPORT SUPPORTED OPERATION CODES".  It 
> has an example CDB usage map that labeled as "the" CDB usage map of 
> "REPORT SUPPORTED OPERATION CODES".
>
> A3h, 0Ch, 03h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is the example.
>
> A3h, 0Ch, 07h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is what I 
> expected at first glance, since the REPORTING OPTION codes go in the 
> three lsb's of byte 2 of the Cdb, and my mask 07h rather than the 
> Pdf's 03h in byte 2 would be a mask of three lsb's rather than two lsb's.
>
> Is 07h rather than 03h in byte 2 yes obviously what we meant to type, 
> or have I misunderstood, or is something interesting happening here?
>
> Curiously yours,
>
> * * For T10 Reflector information, send a message with * 'info t10' 
> (no quotes) in the message body to majordomo at t10.org 


From Elliott at hp.com  Wed Jan 24 06:53:25 2007
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 24 Jan 2007 08:53:25 -0600
Subject: SAS2 SNW-3 SP29:SAS_Train
Message-ID: <mailman.60.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701240_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0701240_smime.p7s">smime.p7s</A>

That state is waiting for the SP receiver to report Training Completed
(meaning the receiver itself is satisfied with the incoming data stream),
not that it has detected any particular incoming TRAIN or TRAIN_DONE
(indicating the state of the other phy).
Training Completed is in the list of messages defined earlier in the
proposal, but is never used again; it was supposed to have been used here.
That correction will be incorporated into sas2r08.
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Craig Stoops
Sent: Tuesday, January 23, 2007 4:24 PM
To: t10 at t10.org
Subject: SAS2 SNW-3 SP29:SAS_Train
Steve, Rob and other interested parties,
Per the latest 6Gb SNW-3 proposal pasted below, the TRAIN Completed message
is not defined in the document. Based on my read of other parts, I think
this should be "TRAIN Transmitted message" as the requirement per
6.7.4.2.3.3 is to send at least 1 TRAIN pattern and after achieving receiver
sync, then transition to sending TRAIN_DONE. 
6.8.4.12.4 Transition SP29:SAS_Train to SP30:SAS_TrainingDone
This transition shall occur if:
a) this state receives a TRAIN Completed message before the TLT timer
expires; and
b) dword synchronization is acquired.
Second point - becuase one end device may be capable of acheiving rx sync
faster than the other, it is possible (as seen by our modeling) for the
slower device to be in SP29 and before that device gains sync the faster
device starts sending TRAIN_DONE.
So it can not be a condition of SP29 -> SP30 to receive a TRAIN pattern, but
rather either TRAIN or a TRAIN_DONE pattern This is implied by aquiring
receiver synchronization.. Currently, as it is undefined, some people may
consider the TRAIN Completed message to be TRAIN Received messsage.
I think it should be further clarified, as I beleive was the original
intention, that both TRAIN and TRAIN_DONE serve to allow a receiver to gain
synchronization. If true, then the slow device will transition from SP29 to
SP30 when gaining rx sync even though it is receiving TRAIN_DONE and not
TRAIN.
Basically, in summary, rewording 6.8.4.12.4 to:
  This transition shall occur after:  
    a) Transmitting at least 1 complete TRAIN pattern (or said the spec way,
after having received at least one TRAIN Transmitted message)
   b) Receiver DWORD synchronization is acquired
Thoughts?
Craig Stoops
ExpertIO, Inc
www.expertio.com
805-428-0839


From steve.finch at st.com  Wed Jan 24 06:54:19 2007
From: steve.finch at st.com (Stephen FINCH)
Date: Wed, 24 Jan 2007 07:54:19 -0700
Subject: SAS2 SNW-3 SP29:SAS_Train
Message-ID: <mailman.61.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701241_f.htm">HTML-formatted message</A>

You are right that there is an error here.  But your solution is not the
correct one.
"a) this state receives a TRAIN Completed message before the TLT timer
expires; and"
should read
"a) this state receives a TRAINing Completed message before the TLT timer
expires; and"
This message is generated by the receiver.  See 6.8.2, item i in the fourth
a/b/c list.
Regards,
Steve Finch
STMicroelectronics, Inc
303 381-3587
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Craig Stoops
Sent: Tuesday, January 23, 2007 3:24 PM
To: t10 at t10.org
Subject: SAS2 SNW-3 SP29:SAS_Train
Steve, Rob and other interested parties,
Per the latest 6Gb SNW-3 proposal pasted below, the TRAIN Completed message
is not defined in the document. Based on my read of other parts, I think
this should be "TRAIN Transmitted message" as the requirement per
6.7.4.2.3.3 is to send at least 1 TRAIN pattern and after achieving receiver
sync, then transition to sending TRAIN_DONE. 
6.8.4.12.4 Transition SP29:SAS_Train to SP30:SAS_TrainingDone
This transition shall occur if:
a) this state receives a TRAIN Completed message before the TLT timer
expires; and
b) dword synchronization is acquired.
Second point - becuase one end device may be capable of acheiving rx sync
faster than the other, it is possible (as seen by our modeling) for the
slower device to be in SP29 and before that device gains sync the faster
device starts sending TRAIN_DONE.
So it can not be a condition of SP29 -> SP30 to receive a TRAIN pattern, but
rather either TRAIN or a TRAIN_DONE pattern This is implied by aquiring
receiver synchronization.. Currently, as it is undefined, some people may
consider the TRAIN Completed message to be TRAIN Received messsage.
I think it should be further clarified, as I beleive was the original
intention, that both TRAIN and TRAIN_DONE serve to allow a receiver to gain
synchronization. If true, then the slow device will transition from SP29 to
SP30 when gaining rx sync even though it is receiving TRAIN_DONE and not
TRAIN.
Basically, in summary, rewording 6.8.4.12.4 to:
  This transition shall occur after:  
    a) Transmitting at least 1 complete TRAIN pattern (or said the spec way,
after having received at least one TRAIN Transmitted message)
   b) Receiver DWORD synchronization is acquired
Thoughts?
Craig Stoops
ExpertIO, Inc
www.expertio.com
805-428-0839


From craig at expertio.com  Wed Jan 24 08:16:44 2007
From: craig at expertio.com (Craig Stoops)
Date: Wed, 24 Jan 2007 08:16:44 -0800
Subject: SAS2 SNW-3 SP29:SAS_Train
Message-ID: <mailman.62.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701242_f.htm">HTML-formatted message</A>

Hi Rob and Steve,
I see the receiver is supposed to send this message, but I do not see any
definition of what the conditions are for generating this message.
It also doesn't say that the message is only sent after DWS has obtains
synchronization as it does with ALIGN Receieved and TRAIN_DONE Received.
It would seem to me, that Training Completed is the same as SP_DWS Sync
Aquired. The point being to lock the rx pll, then the dws will sync. 
I am refering to 06-515R0 as I don't see a revision posted on t10.
Can you point me the way to which section has the definition of Training
Completed? I particularly want to know if this message generation requires a
certain number of patterns and of what type to be seen to qualify it.
Thanks,
Craig
ExpertIO, Inc
www.expertio.com
805-428-0839
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Wednesday, January 24, 2007 6:53 AM
To: t10 at t10.org
Subject: RE: SAS2 SNW-3 SP29:SAS_Train
That state is waiting for the SP receiver to report Training Completed
(meaning the receiver itself is satisfied with the incoming data stream),
not that it has detected any particular incoming TRAIN or TRAIN_DONE
(indicating the state of the other phy).
Training Completed is in the list of messages defined earlier in the
proposal, but is never used again; it was supposed to have been used here.
That correction will be incorporated into sas2r08.
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Craig Stoops
Sent: Tuesday, January 23, 2007 4:24 PM
To: t10 at t10.org
Subject: SAS2 SNW-3 SP29:SAS_Train
Steve, Rob and other interested parties,
Per the latest 6Gb SNW-3 proposal pasted below, the TRAIN Completed message
is not defined in the document. Based on my read of other parts, I think
this should be "TRAIN Transmitted message" as the requirement per
6.7.4.2.3.3 is to send at least 1 TRAIN pattern and after achieving receiver
sync, then transition to sending TRAIN_DONE. 
6.8.4.12.4 Transition SP29:SAS_Train to SP30:SAS_TrainingDone
This transition shall occur if:
a) this state receives a TRAIN Completed message before the TLT timer
expires; and
b) dword synchronization is acquired.
Second point - becuase one end device may be capable of acheiving rx sync
faster than the other, it is possible (as seen by our modeling) for the
slower device to be in SP29 and before that device gains sync the faster
device starts sending TRAIN_DONE.
So it can not be a condition of SP29 -> SP30 to receive a TRAIN pattern, but
rather either TRAIN or a TRAIN_DONE pattern This is implied by aquiring
receiver synchronization.. Currently, as it is undefined, some people may
consider the TRAIN Completed message to be TRAIN Received messsage.
I think it should be further clarified, as I beleive was the original
intention, that both TRAIN and TRAIN_DONE serve to allow a receiver to gain
synchronization. If true, then the slow device will transition from SP29 to
SP30 when gaining rx sync even though it is receiving TRAIN_DONE and not
TRAIN.
Basically, in summary, rewording 6.8.4.12.4 to:
  This transition shall occur after:  
    a) Transmitting at least 1 complete TRAIN pattern (or said the spec way,
after having received at least one TRAIN Transmitted message)
   b) Receiver DWORD synchronization is acquired
Thoughts?
Craig Stoops
ExpertIO, Inc
www.expertio.com
805-428-0839


From steve.finch at st.com  Wed Jan 24 09:54:31 2007
From: steve.finch at st.com (Stephen FINCH)
Date: Wed, 24 Jan 2007 10:54:31 -0700
Subject: SAS2 SNW-3 SP29:SAS_Train
Message-ID: <mailman.63.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701243_f.htm">HTML-formatted message</A>

Here are my comments/thoughts:
Training Complete is generated by the physical layer receiver.	How, why,
when is implementation specific and probably will not be defined by the PHY
working group (although my comment here is not binding on the WG).
Training Completed is not a function of any received dword or primitive, so
it does not _require_ dword synchronization to occur.
06-515r0 (this is the latest revision) requires SP_DWS Sync Acquired and
Training Completed to move forward in the state machine.  The order of these
two events is not specified.
Regards,
Steve
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Craig Stoops
Sent: Wednesday, January 24, 2007 9:17 AM
To: t10 at t10.org
Subject: RE: SAS2 SNW-3 SP29:SAS_Train
Hi Rob and Steve,
I see the receiver is supposed to send this message, but I do not see any
definition of what the conditions are for generating this message.
It also doesn't say that the message is only sent after DWS has obtains
synchronization as it does with ALIGN Receieved and TRAIN_DONE Received.
It would seem to me, that Training Completed is the same as SP_DWS Sync
Aquired. The point being to lock the rx pll, then the dws will sync. 
I am refering to 06-515R0 as I don't see a revision posted on t10.
Can you point me the way to which section has the definition of Training
Completed? I particularly want to know if this message generation requires a
certain number of patterns and of what type to be seen to qualify it.
Thanks,
Craig
ExpertIO, Inc
www.expertio.com
805-428-0839
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Wednesday, January 24, 2007 6:53 AM
To: t10 at t10.org
Subject: RE: SAS2 SNW-3 SP29:SAS_Train
That state is waiting for the SP receiver to report Training Completed
(meaning the receiver itself is satisfied with the incoming data stream),
not that it has detected any particular incoming TRAIN or TRAIN_DONE
(indicating the state of the other phy).
Training Completed is in the list of messages defined earlier in the
proposal, but is never used again; it was supposed to have been used here.
That correction will be incorporated into sas2r08.
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Craig Stoops
Sent: Tuesday, January 23, 2007 4:24 PM
To: t10 at t10.org
Subject: SAS2 SNW-3 SP29:SAS_Train
Steve, Rob and other interested parties,
Per the latest 6Gb SNW-3 proposal pasted below, the TRAIN Completed message
is not defined in the document. Based on my read of other parts, I think
this should be "TRAIN Transmitted message" as the requirement per
6.7.4.2.3.3 is to send at least 1 TRAIN pattern and after achieving receiver
sync, then transition to sending TRAIN_DONE. 
6.8.4.12.4 Transition SP29:SAS_Train to SP30:SAS_TrainingDone
This transition shall occur if:
a) this state receives a TRAIN Completed message before the TLT timer
expires; and
b) dword synchronization is acquired.
Second point - becuase one end device may be capable of acheiving rx sync
faster than the other, it is possible (as seen by our modeling) for the
slower device to be in SP29 and before that device gains sync the faster
device starts sending TRAIN_DONE.
So it can not be a condition of SP29 -> SP30 to receive a TRAIN pattern, but
rather either TRAIN or a TRAIN_DONE pattern This is implied by aquiring
receiver synchronization.. Currently, as it is undefined, some people may
consider the TRAIN Completed message to be TRAIN Received messsage.
I think it should be further clarified, as I beleive was the original
intention, that both TRAIN and TRAIN_DONE serve to allow a receiver to gain
synchronization. If true, then the slow device will transition from SP29 to
SP30 when gaining rx sync even though it is receiving TRAIN_DONE and not
TRAIN.
Basically, in summary, rewording 6.8.4.12.4 to:
  This transition shall occur after:  
    a) Transmitting at least 1 complete TRAIN pattern (or said the spec way,
after having received at least one TRAIN Transmitted message)
   b) Receiver DWORD synchronization is acquired
Thoughts?
Craig Stoops
ExpertIO, Inc
www.expertio.com
805-428-0839


From plavarre at lexar.com  Thu Jan 25 09:09:25 2007
From: plavarre at lexar.com (Pat LaVarre)
Date: Thu, 25 Jan 2007 09:09:25 -0800
Subject: mask x07 or x03 defines Rsoc Cdb byte 2
Message-ID: <mailman.64.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701250_f.htm">HTML-formatted message</A>

Ralph,
Thank you, yes we agree.  Sorry I went wrong by still remembering some
of Spc4r07a.pdf while now speaking of Spc4r08.pdf, ouch.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph
Weber
Sent: Tuesday, January 23, 2007 8:24 PM
To: T10 Reflector
Subject: Re: mask x07 or x03 defines Rsoc Cdb byte 2
Pat,
My review of SPC-4 r08 indicates that your comment is
almost right.
CDB byte 2 does contain a 3-bit field in the low-order
bits and that makes your proposed change from 03h to 07h
correct ... as far as it goes.
However, SPC-4 r08 adds the command timeouts reporting
option to the REPORT SUPPORTED OPERATION CODES command.
This new feature defines bit 7 of byte 2 as the RCTD
(Return Command Timeouts Descriptor) bit. When this
change is added to the issue which you have reported
the cited byte needs to change from 03h to 87h.
Unless I hear objections, I will made this change
in SPC-4 r09.
All the best,
.Ralph
Pat LaVarre wrote: 
* From the T10 Reflector (t10 at t10.org), posted by: * "Pat LaVarre" * 
Spc4r08.pdf at p.231 discusses "REPORT SUPPORTED OPERATION CODES".  It
has an example CDB usage map that labeled as "the" CDB usage map of
"REPORT SUPPORTED OPERATION CODES".
A3h, 0Ch, 03h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is the
example.
A3h, 0Ch, 07h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is what I
expected at first glance, since the REPORTING OPTION codes go in the
three lsb's of byte 2 of the Cdb, and my mask 07h rather than the Pdf's
03h in byte 2 would be a mask of three lsb's rather than two lsb's.
Is 07h rather than 03h in byte 2 yes obviously what we meant to type, or
have I misunderstood, or is something interesting happening here?
Curiously yours,
* * For T10 Reflector information, send a message with * 'info t10' (no
quotes) in the message body to majordomo at t10.org 


From plavarre at lexar.com  Thu Jan 25 09:37:31 2007
From: plavarre at lexar.com (Pat LaVarre)
Date: Thu, 25 Jan 2007 09:37:31 -0800
Subject: extending Rsoc complicates bootstrap
Message-ID: <mailman.65.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701251_f.htm">HTML-formatted message</A>

Bob,
I like both of these questions, yes thank you.	Likely I'll say more on
the other shortly, meanwhile:
Yes to me the REPORT SUPPORTED OPERATION CODES bootstrap is unclear.
As a host, how do I get from a device that accepts a traditional INQUIRY
(i.e., x 12 0 0 0 24 0 = Cdb, while expecting 0 to x24 data bytes in) up
to knowing I may try one or another specific variation of the REPORT
SUPPORTED OPERATION CODES command, such as this new RCTD variation?
I have no clear idea.
________________________________
From: Sheffield, Robert L [mailto:robert.l.sheffield at intel.com] 
Sent: Tuesday, January 23, 2007 8:29 PM
To: Pat LaVarre; T10 Reflector
Subject: RE: mask x07 or x03 defines Rsoc Cdb byte 2
Wish I could provide an answer, but all I can do is pose two more
follow-on questions:
I notice that while the REPORTING OPTIONS field (lower 3 bits of byte-2
in the REPORT SUPPORTED OPERATION CODES command) is a 3-bit field, the
there are only 3 code values defined for this field (000b, 001b, and
010b - bit-2 is always zero), with code values 011b - 111b reserved. The
rules say, 
	"If the device server evaluates a bit in the CDB for the command
being queried, the usage map shall contain a one in the corresponding
bit position. If any bit representing part of a field is returned as
one, all bits for the field shall be returned as one. If the device
server ignores or treats as reserved a bit in the CDB for the command
being queried, the usage map shall contain a zero in the corresponding
bit position."
The first sentence says report three bits worth of "1". If one could
interpret the fact that the reserved code values cover all the values
where the high-order bit is set to 1, that the high order bit is
therefore reserved, then the rule in the second sentence might lead to
setting only the lower-order two bits to "1", and the high-order bit to
zero. But I don't think that's the intent, so I think you are correct,
7h is correct.
The other more interesting question is why isn't byte-2 equal to 87h
(rather than 07h). Does this mean that the device server in the example
treats the RCTD bit as reserved? Are device servers that support the
REPORT SUPPORTED OPERATION CODES command required to support an RCTD bit
set to one? If not, then presumably the device server could report
either 07h or 87h in byte-2 of the CDB usage map for the REPORT
SUPOPRTED OPERATION CODES CDB.
Either way - looks like something to fix in SPC-4.
Bob Sheffield
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pat
LaVarre
Sent: Tuesday, January 23, 2007 5:16 PM
To: T10 Reflector
Subject: mask x07 or x03 defines Rsoc Cdb byte 2
* From the T10 Reflector (t10 at t10.org), posted by: * "Pat LaVarre" * 
Spc4r08.pdf at p.231 discusses "REPORT SUPPORTED OPERATION CODES".  It
has an example CDB usage map that labeled as "the" CDB usage map of
"REPORT SUPPORTED OPERATION CODES".
A3h, 0Ch, 03h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is the
example.
A3h, 0Ch, 07h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is what I
expected at first glance, since the REPORTING OPTION codes go in the
three lsb's of byte 2 of the Cdb, and my mask 07h rather than the Pdf's
03h in byte 2 would be a mask of three lsb's rather than two lsb's.
Is 07h rather than 03h in byte 2 yes obviously what we meant to type, or
have I misunderstood, or is something interesting happening here?
Curiously yours,
* * For T10 Reflector information, send a message with * 'info t10' (no
quotes) in the message body to majordomo at t10.org 


From plavarre at lexar.com  Thu Jan 25 09:57:47 2007
From: plavarre at lexar.com (Pat LaVarre)
Date: Thu, 25 Jan 2007 09:57:47 -0800
Subject: Rsoc descriptions vary merely by intent maybe
Message-ID: <mailman.66.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701252_f.htm">HTML-formatted message</A>

Bob,
Yes to me the Cdb Usage mask distinctions between a reserved bit, an
always zero bit, and an always one bit remain unclear.
Just suppose ...
Yesterday, the spec defined only 00b and 01b and 10b.  We mass-produced
those devices.	Today the spec changes.  We tell some idiot compiler
only that the device shall interpret 000b and 001b and 010b.  We
unconsciously end up mass-producing devices that actually discard the
top bit of the field and thus again actually distinguish only 00b and
01b and 10b.
In this way, we change our intent from yesterday to today, but we
actually produce the same device design twice.	Still at T10 our intent
is to say that the correct Rsoc description of these devices does
differ.  Merely because we had more bits in mind as we made today's
device, now mask x07 is its correct self-description, whereas mask x03
was the correct self-description of yesterday's physically identical
device.
So far so good?
Then, whether mask x03 or mask x07 is correct for any actual device is
not a testable specification - it's merely a matter of unobservable
intent - the mask is a kind of pointer to a particular part of the spec
found in one revision or another.  As device people, we encode that
pointer as the list of bits defined in the part of that spec that we
bothered to read, that's all.
Is this a correct interpretation?
Funny but true?  I'm not trying to be dense - this is where I arrive
logically, courtesy my vast ignorance.	  Yes I see now, our
unelaborated text as it stands arguably contradicts itself.  Until you
helped me pause and focus, I wasn't clear on this question - and if you
object in reply, then I've still got it wrong!
To clarify the text, we could try to talk more often of fields, less
often of bits, e.g.:
"If the device server evaluates a bit in the CDB for the command being
queried, the usage map shall contain a one in the corresponding bit
position. If any bit representing part of a field is returned as one,
all bits for the field shall be returned as one. If the device server
ignores or treats as reserved a [+field] [-bit] in the CDB for the
command being queried, the usage map shall contain a zero in [+all] the
corresponding bit position[+s]."
The difficulty of fields growing over time might also be worth inserting
a sentence, e.g.:
"When the device server complies with two or more specifications that
disagree over how many or which bits are all the bits of the field, then
the usage map shall match only the specification that takes precedence."
Hope this helps,
________________________________
From: Sheffield, Robert L [mailto:robert.l.sheffield at intel.com] 
Sent: Tuesday, January 23, 2007 8:29 PM
To: Pat LaVarre; T10 Reflector
Subject: RE: mask x07 or x03 defines Rsoc Cdb byte 2
Wish I could provide an answer, but all I can do is pose two more
follow-on questions:
I notice that while the REPORTING OPTIONS field (lower 3 bits of byte-2
in the REPORT SUPPORTED OPERATION CODES command) is a 3-bit field, the
there are only 3 code values defined for this field (000b, 001b, and
010b - bit-2 is always zero), with code values 011b - 111b reserved. The
rules say, 
	"If the device server evaluates a bit in the CDB for the command
being queried, the usage map shall contain a one in the corresponding
bit position. If any bit representing part of a field is returned as
one, all bits for the field shall be returned as one. If the device
server ignores or treats as reserved a bit in the CDB for the command
being queried, the usage map shall contain a zero in the corresponding
bit position."
The first sentence says report three bits worth of "1". If one could
interpret the fact that the reserved code values cover all the values
where the high-order bit is set to 1, that the high order bit is
therefore reserved, then the rule in the second sentence might lead to
setting only the lower-order two bits to "1", and the high-order bit to
zero. But I don't think that's the intent, so I think you are correct,
7h is correct.
The other more interesting question is why isn't byte-2 equal to 87h
(rather than 07h). Does this mean that the device server in the example
treats the RCTD bit as reserved? Are device servers that support the
REPORT SUPPORTED OPERATION CODES command required to support an RCTD bit
set to one? If not, then presumably the device server could report
either 07h or 87h in byte-2 of the CDB usage map for the REPORT
SUPOPRTED OPERATION CODES CDB.
Either way - looks like something to fix in SPC-4.
Bob Sheffield
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pat
LaVarre
Sent: Tuesday, January 23, 2007 5:16 PM
To: T10 Reflector
Subject: mask x07 or x03 defines Rsoc Cdb byte 2
* From the T10 Reflector (t10 at t10.org), posted by: * "Pat LaVarre" * 
Spc4r08.pdf at p.231 discusses "REPORT SUPPORTED OPERATION CODES".  It
has an example CDB usage map that labeled as "the" CDB usage map of
"REPORT SUPPORTED OPERATION CODES".
A3h, 0Ch, 03h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is the
example.
A3h, 0Ch, 07h, FFh, FFh, FFh, FFh, FFh, FFh, FFh, 00h, 07h is what I
expected at first glance, since the REPORTING OPTION codes go in the
three lsb's of byte 2 of the Cdb, and my mask 07h rather than the Pdf's
03h in byte 2 would be a mask of three lsb's rather than two lsb's.
Is 07h rather than 03h in byte 2 yes obviously what we meant to type, or
have I misunderstood, or is something interesting happening here?
Curiously yours,
* * For T10 Reflector information, send a message with * 'info t10' (no
quotes) in the message body to majordomo at t10.org 


From clyon at scsita.org  Thu Jan 25 10:31:54 2007
From: clyon at scsita.org (Chris Lyon)
Date: Thu, 25 Jan 2007 10:31:54 -0800
Subject: STA T-10 Memphis Hotel (one more time)
Message-ID: <mailman.67.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701253_f.htm">HTML-formatted message</A>

Dear T-10 and STA members,
I have heard from a few of you that you have still been having	
trouble booking rooms for the  March meetings.	I have contacted the  
Hotel again and had them add more rooms to Sunday and Monday so we  
should have you covered now.  Here is the booking link again and if  
anyone still has trouble please contact me directly.
http://marriott.com/property/propertypage/memdt? 
groupCode=scsscsa&app=resvlink
Regards,
Chris Lyon
-=-=-=-=-=-=- SCSI Trade Association -=-=-=-=-=-=-
Chris Lyon, CAE 			Tel. +1.425.286.1111
Executive Director			Fax +1.425.488.3646
18221 102nd Ave N.E.		  E-mail: Clyon at scsita.org
Bothell, WA 98011		       http://www.scsita.org
The SCSI Trade Association is managed by LoBue & Majdalany Management  
Group, an IAAMC Charter Accredited  
Firm._______________________________________________


From clyon at scsita.org  Thu Jan 25 10:31:54 2007
From: clyon at scsita.org (Chris Lyon)
Date: Thu, 25 Jan 2007 10:31:54 -0800
Subject: [STA Members] STA T-10 Memphis Hotel (one more time)
Message-ID: <mailman.68.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701254_f.htm">HTML-formatted message</A>

Dear T-10 and STA members,
I have heard from a few of you that you have still been having	
trouble booking rooms for the  March meetings.	I have contacted the  
Hotel again and had them add more rooms to Sunday and Monday so we  
should have you covered now.  Here is the booking link again and if  
anyone still has trouble please contact me directly.
http://marriott.com/property/propertypage/memdt? 
groupCode=scsscsa&app=resvlink
Regards,
Chris Lyon
-=-=-=-=-=-=- SCSI Trade Association -=-=-=-=-=-=-
Chris Lyon, CAE 			Tel. +1.425.286.1111
Executive Director			Fax +1.425.488.3646
18221 102nd Ave N.E.		  E-mail: Clyon at scsita.org
Bothell, WA 98011		       http://www.scsita.org
The SCSI Trade Association is managed by LoBue & Majdalany Management  
Group, an IAAMC Charter Accredited  
Firm._______________________________________________


From keiji_katata at post.pioneer.co.jp  Thu Jan 25 16:20:41 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 26 Jan 2007 09:20:41 +0900
Subject: Inquiry about: Request to move February Mt Fuji meeting dates
Message-ID: <mailman.69.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I would like to ask all members that you can accept this date change or not.
I will wait for 1 week. If you do not accept this date change, please send
your
opinion to reflector by Feb 2nd of Japan time. It is Feb 1st of USA time.
If we have no objection, we will move the meeting date from 14-15 to 21-22.
One more subject.
We now expect March meeting at T10 place on March 13-14. The Feb. 21 is the
date
which passed over a term called three-week before. Do you have any opinion
the
March meeting date/place?
I think that T10 place is like the mecca for which SCSI people gather. So we
may
keep our current plan.
(Since I visited Seattle and San Francisco repeatedly, I got bored a little.
Memphis sounds good.)
Let me know your opinion.
Best regards,
Keiji Katata
PIONEER CORP.
David Walp <David.Walp at microsoft.com>@avc-pioneer.com on 2007/01/26 08:47:44
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>
cc:
bcc:
$B7oL>(B:  Request to move February Mt Fuji meeting dates
Hi,
Microsoft requests the dates of the February Mt Fuji meeting to be moved from
the 14th & 15th to 21st & 22nd.  Unfortunately, we currently would be unable
to
attend the meeting if held on the earlier dates, which why we initially
suggest
dates for the week of Feb 19th.  Microsoft considers the ongoing discussion
at
Mt Fuji very important and thus we are planning to send two people to the
meeting if held on the 21st & 22nd.
Kindly, Katata-san has worked with Mine-san from Sony and they were already
able
to reserve a meeting space at Tokyo Osaki for the 21st and 22nd.
Our understanding is that Katata-san will be sending email to poll your
opinion.
Thank you for your consideration,
_dave_
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Elliott at hp.com  Fri Jan 26 11:57:35 2007
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Fri, 26 Jan 2007 13:57:35 -0600
Subject: SAS-2 revision 8 now available
Message-ID: <mailman.70.1441607320.22512.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0701260_smime.p7s">smime.p7s</A>

Serial Attached SCSI - 2 (SAS-2) revision 8 (sas2r08) is now available
on http://www.t10.org/drafts.htm and http://www.t10.org/new.htm, 
incorporating proposals recommended by the January 2007 T10 plenary
(e.g., the new speed negotiation definition).
The goal for T10 letter ballot is July 2007; the 6 Gbps physical
layer specifications will probably be the gating item.	Please:
* review the editor's notes that have accumulated
* review pending proposals and send comments to their authors. 
  The current WG agendas are at:
  - http://www.t10.org/ftp/t10/sas-agnd.htm and 
  - http://www.t10.org/ftp/t10/phy-agnd.htm
* prepare proposals for any other changes you want in time 
  for the March meeting
We will probably hold interim SAS protocol and physical WG meetings
on April 17-19 (Tue-Thu) in Houston, TX.  Let me know if those dates
are a problem.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


From lohmeyer at t10.org  Sat Jan 27 23:01:30 2007
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 28 Jan 2007 00:01:30 -0700
Subject: Recent T10 documents uploaded since 2007/01/21
Message-ID: <mailman.71.1441607320.22512.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAS-2: Initiator handling of retransmit read DATA frames
(by: Vicky Duerk/Bob Sheffield)
T10/06-467r2   Uploaded: 2007/01/27   46266 bytes
ftp://ftp.t10.org/t10/document.06/06-467r2.pdf
SAT-2: Work Items and Open Issues List
(by: Mark Overby)
T10/06-497r3   Uploaded: 2007/01/22   19394 bytes
ftp://ftp.t10.org/t10/document.06/06-497r3.pdf
SAS-2 10 Meter Cable Specification Issues
(by: Barry Olawsky)
T10/06-499r1   Uploaded: 2007/01/25   121202 bytes
ftp://ftp.t10.org/t10/document.06/06-499r1.pdf
SAS-2 Transmitter/Receiver S-Parameter Measurements
(by: Barry Olawsky)
T10/07-012r1   Uploaded: 2007/01/25   333499 bytes
ftp://ftp.t10.org/t10/document.07/07-012r1.pdf
Minutes of T10 Plenary Meeting #77 - January 18, 2007
(by: Weber & Lohmeyer)
T10/07-034r0   Uploaded: 2007/01/23   111081 bytes
ftp://ftp.t10.org/t10/document.07/07-034r0.htm
Minutes of T10 Plenary Meeting #77 - January 18, 2007
(by: Weber & Lohmeyer)
T10/07-034r0   Uploaded: 2007/01/23   301641 bytes
ftp://ftp.t10.org/t10/document.07/07-034r0.pdf
SPC-4: Editorial change: IEEE P1667 to IEEE 1667
(by: Avraham Shimor)
T10/07-056r0   Uploaded: 2007/01/25   15448 bytes
ftp://ftp.t10.org/t10/document.07/07-056r0.pdf
SAS-2 OOB and SSC
(by: Stephen Finch)
T10/07-058r0   Uploaded: 2007/01/25   66102 bytes
ftp://ftp.t10.org/t10/document.07/07-058r0.pdf
SAS-2 Update SATA references to Serial ATA 2.6
(by: Rob Elliott)
T10/07-059r0   Uploaded: 2007/01/25   21397 bytes
ftp://ftp.t10.org/t10/document.07/07-059r0.pdf
Working Drafts
--------------
Object-Based Storage Devices - 2 (OSD-2)
(Editor: Ralph Weber)
 Rev: 01       Uploaded: 2007/01/22   1483180 bytes
ftp://ftp.t10.org/t10/drafts/osd2/osd2r01.pdf
SCSI Architecture Model - 4 (SAM-4)
(Editor: George Penokie)
 Rev: 09       Uploaded: 2007/01/22   1144360 bytes
ftp://ftp.t10.org/t10/drafts/sam4/sam4r09.pdf
Serial Attached SCSI - 2 (SAS-2)
(Editor: Rob Elliott)
 Rev: 08       Uploaded: 2007/01/26   6744201 bytes
ftp://ftp.t10.org/t10/drafts/sas2/sas2r08.pdf
SCSI Block Commands - 3 (SBC-3)
(Editor: George Penokie)
 Rev: 08       Uploaded: 2007/01/22   1475008 bytes
ftp://ftp.t10.org/t10/drafts/sbc3/sbc3r08.pdf
SCSI Block Commands - 3 (SBC-3)
(Editor: George Penokie)
 Rev: 08a      Uploaded: 2007/01/23   1473069 bytes
ftp://ftp.t10.org/t10/drafts/sbc3/sbc3r08a.pdf
(Report generated on 2007/01/28 at 00:01:29)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Mon Jan 29 02:33:52 2007
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 29 Jan 2007 19:33:52 +0900
Subject: Draft Minutes and delivered document posted
Message-ID: <mailman.72.1441607320.22512.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 Minutes and all delivered document.
Please pick them up from ftp.
ftp.avc-pioneer.com/Mtfuji_7/Minutes
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Jan07
Sorry for the late posting.
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 Alvin.Cox at seagate.com  Wed Jan 31 14:10:46 2007
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 31 Jan 2007 16:10:46 -0600
Subject: Reminder: SAS PHY WG conference call 2/1/07 10:00am CST
Message-ID: <mailman.73.1441607320.22512.t10@sandbox.t10.org>

Formatted message: <A HREF="r0701310_f.htm">HTML-formatted message</A>

Next conference call February 1, 2007 
Agenda:
1.) 10/07-058r0 SAS-2 OOB and SSC [Finch]
ftp://ftp.t10.org/t10/document.07/07-058r0.pdf
2.) New items.
3.) Review of PHY specification proposal. (Alvin is working on it but not 
posted yet. Includes information already presented and discuss some issues 
found while putting it together.)
Weekly teleconferences scheduled for Thursdays at 10 am CST: 
PARTICIPANT INFORMATION: 
Toll Free Dial in Number: (866) 279-4742 
International Access/Caller Paid Dial In Number: (309) 229-0118 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809