From Mark.Evans at wdc.com  Wed Nov  1 09:31:03 2006
From: Mark.Evans at wdc.com (Mark Evans)
Date: Wed, 1 Nov 2006 09:31:03 -0800
Subject: REPORT DEVICE IDENTIFIER/REPORT IDENTIFYING INFORMATION
Message-ID: <mailman.921.1441607310.22510.t10@sandbox.t10.org>

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

Hello,
In SBC-3 r07 and SPCs before SPC-4 r07 there is/was a command named REPORT
DEVICE IDENTIFIER.  This is a version of the MAINTENANCE (IN) command with
service action REPORT PERIPHERAL DEVICE/COMPONENT DEVICE IDENTIFIER (command
code A3h, service action code 05h) defined in SSC-2 r04.
In SPC-4 r07 this command was renamed REPORT IDENTIFYING INFORMATION.  I
think this may have been an artifact of Paul Entzel's proposal 06-278r0.
One way or the other, SBC-3 should use the new name for the command.  I also
think it would be helpful to add something like "this command was named
REPORT DEVICE IDENTIFIER in previous versions of this standard" into SPC,
and "this command was named REPORT DEVICE IDENTIFIER in previous versions of
SPC" into SBC.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose,  CA  95138
Email: mark.evans at wdc.com
Office: 408.363.5257
Fax: 408.363.5139
Cell: 408.391.7805


From roweber at IEEE.org  Wed Nov  1 12:03:28 2006
From: roweber at IEEE.org (Ralph Weber)
Date: Wed, 01 Nov 2006 14:03:28 -0600
Subject: REPORT DEVICE IDENTIFIER/REPORT IDENTIFYING INFORMATION
Message-ID: <mailman.922.1441607310.22510.t10@sandbox.t10.org>

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

Mark,
Not that it affects your request to note the old command name,
but the name was changed at the explicit request of CAP in
Rob's proposal, 06-221r3 Peripheral device identifying information.
All the best,
.Ralph
P.S. Welcome back!
Mark Evans wrote:
>
> Hello,
>
> In SBC-3 r07 and SPCs before SPC-4 r07 there is/was a command named 
> REPORT DEVICE IDENTIFIER.  This is a version of the MAINTENANCE (IN) 
> command with service action REPORT PERIPHERAL DEVICE/COMPONENT DEVICE 
> IDENTIFIER (command code A3h, service action code 05h) defined in 
> SSC-2 r04.
>
> In SPC-4 r07 this command was renamed REPORT IDENTIFYING INFORMATION.  
> I think this may have been an artifact of Paul Entzel's proposal 06-278r0.
>
> One way or the other, SBC-3 should use the new name for the command.	
> I also think it would be helpful to add something like "this command 
> was named REPORT DEVICE IDENTIFIER in previous versions of this 
> standard" into SPC, and "this command was named REPORT DEVICE 
> IDENTIFIER in previous versions of SPC" into SBC.
>
> Regards,
>
> Mark Evans
>
> Western Digital Corporation
>
> 5863 Rue Ferrari
>
> San Jose,  CA  95138
>
> Email: mark.evans at wdc.com
>
> Office: 408.363.5257
>
> Fax: 408.363.5139
>
> Cell: 408.391.7805
>


From Alvin.Cox at seagate.com  Wed Nov  1 14:29:35 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 1 Nov 2006 16:29:35 -0600
Subject: SAS PHY WG teleconference 11/2, 10 am CST
Message-ID: <mailman.923.1441607310.22510.t10@sandbox.t10.org>

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

Next conference call November 2, 2006 
Agenda:
1.	 SAS-2 OOB transmission requirements [Cox]
http://www.t10.org/ftp/t10/document.06/06-463r1.pdf
2.	New items.
3.	SAS-2 Modifications to the SAS Speed Negotiation [Finch, Wassal]
http://www.t10.org/ftp/t10/document.06/06-324r7.pdf
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, Nov 2, 2006 
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 David.Walp at microsoft.com  Wed Nov  1 15:03:25 2006
From: David.Walp at microsoft.com (David Walp)
Date: Wed, 1 Nov 2006 15:03:25 -0800
Subject: Consideration of 2/4/7, 2/4/8
Message-ID: <mailman.924.1441607310.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* David Walp <David.Walp at microsoft.com>
*
Hi Katata-san,
Thank you for taking your time in making this proposal.
If I understand correctly, a initial version of this proposal was
discussed at the last Mt Fuji meeting.	Ravinder Thind from Microsoft
was in attendance at that meeting and he expressed deep concern about
this potential direction.
We, including Ravinder Thind, David Burg and Henry Gabryjelski, have
studied your proposal further and our concerns still exist.  Although
this proposal may solve a particular problem, we believe that it will
have the very large negative effect on the existing software
applications.  We further believe going forward with this proposal is
not the best thing for the overall industry.
If this proposal goes forward, drives will become unresponsive to the
host. The host will likely take actions such as resetting the bus to
recover the device.  And this will force a recovery to be done at a
higher level.  We believe few existing applications are prepared to deal
with this type of error.  Adding recover from this type of error will be
adding complexity.  The existing paradigm of reporting 2/4/8, indicates
the drive is busy and allows the application to recover at simple and
low level and we believe many applications have already implement this
approach.
thanks
_dave_
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of
keiji_katata at post.pioneer.co.jp
Sent: Monday, October 30, 2006 3:18 AM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Consideration of 2/4/7, 2/4/8
Hello all,
I put documents about Consideration of 2/4/7, 2/4/8.
Please pick up and study them.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Nov06/Pioneer/247-248/
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 keiji_katata at post.pioneer.co.jp  Wed Nov  1 18:46:54 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 2 Nov 2006 11:46:54 +0900
Subject: Revised RW-DL document
Message-ID: <mailman.925.1441607310.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I put revised RW-DL document according to the result of the last meeting
Please pick up and study them.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Nov06/Pioneer/
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 Mark.Evans at wdc.com  Thu Nov  2 07:02:23 2006
From: Mark.Evans at wdc.com (Mark Evans)
Date: Thu, 2 Nov 2006 07:02:23 -0800
Subject: REPORT DEVICE IDENTIFIER/REPORT IDENTIFYING INFORMATION
Message-ID: <mailman.926.1441607310.22510.t10@sandbox.t10.org>

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

Hi Ralph,
Thanks for the welcome back.  You'll get to see me in person in just four
days -- ha!  I was a little hasty in my first email, sending it off before I
realized that the related command, SET IDENTIFYING INFORMATION, should also
have a note as to its genesis.
Regards,
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose,  CA  95138
Email: mark.evans at wdc.com
Office: 408.363.5257
Fax: 408.363.5139
Cell: 408.391.7805
________________________________
From: owner-t10 at t10.org on behalf of Ralph Weber
Sent: Wed 11/1/2006 12:03 PM
To: t10 at t10.org
Subject: Re: REPORT DEVICE IDENTIFIER/REPORT IDENTIFYING INFORMATION
Mark,
Not that it affects your request to note the old command name,
but the name was changed at the explicit request of CAP in
Rob's proposal, 06-221r3 Peripheral device identifying information.
All the best,
.Ralph
P.S. Welcome back!
Mark Evans wrote: 
	Hello,
	In SBC-3 r07 and SPCs before SPC-4 r07 there is/was a command named
REPORT DEVICE IDENTIFIER.  This is a version of the MAINTENANCE (IN) command
with service action REPORT PERIPHERAL DEVICE/COMPONENT DEVICE IDENTIFIER
(command code A3h, service action code 05h) defined in SSC-2 r04.
	In SPC-4 r07 this command was renamed REPORT IDENTIFYING
INFORMATION.  I think this may have been an artifact of Paul Entzel's
proposal 06-278r0.
	One way or the other, SBC-3 should use the new name for the command.
I also think it would be helpful to add something like "this command was
named REPORT DEVICE IDENTIFIER in previous versions of this standard" into
SPC, and "this command was named REPORT DEVICE IDENTIFIER in previous
versions of SPC" into SBC.
	Regards,
	Mark Evans
	Western Digital Corporation
	5863 Rue Ferrari
	San Jose,  CA  95138
	Email: mark.evans at wdc.com
	Office: 408.363.5257
	Fax: 408.363.5139
	Cell: 408.391.7805


From matt.ball at quantum.com  Fri Nov  3 07:42:59 2006
From: matt.ball at quantum.com (Matt Ball)
Date: Fri, 3 Nov 2006 08:42:59 -0700
Subject: SPC-4: 06-449r0 "Establishing a Security Association using IKEv2" now available
Message-ID: <mailman.927.1441607310.22510.t10@sandbox.t10.org>

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

Hi All,
Just a quick heads-up: David Black and I have posted 06-449r0 to the T10
website.  See document at:
<http://www.t10.org/ftp/t10/document.06/06-449r0.pdf&gt;
This proposal describes a method for creating a 'security association'
(SA) over SCSI.  An SA allows encryption of traffic, such as encryption
keys, over the interface.  If you are interested in security-related
proposals, please take a look and let David and me know if you have any
questions or comments.
Thanks,
-Matt


From cds at cisco.com  Fri Nov  3 13:38:08 2006
From: cds at cisco.com (Claudio DeSanti)
Date: Fri, 03 Nov 2006 13:38:08 -0800
Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT
Message-ID: <mailman.928.1441607310.22510.t10@sandbox.t10.org>

Craig, Bob, Dave,
there are functions defined in FCP-4, such as data overlay or certain 
bi-directional commands, that are simply not implementable in Class 3 
without the use of CISC. I bet that the devices you are referring to do 
not implement these functions. I recommend to identify these functions 
in FCP-4 and either:
a) obsolete them; or
b) clearly state that use of CISC is required to implement them in Class 3.
In addition, the usage of CISC greatly simplifies error recovery in 
Class 3. We should encourage this behavior moving forward. I recommend 
that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but 
not its use. CISC should be mandatory to support and optional to use in 
FCP-4. In this way we set a good path for the future, while allowing 
complete interoperability with FCP-3 and older devices that do not 
support CISC. To ease this interoperability FCP-4 may also recommend to 
not use CISC by default. But mandating its support in FCP-4 devices, we 
achieve that when connecting FCP-4 only devices CISC may be turned on 
and used, with all its advantages.
Thanks,
Claudio.
Craig W. Carlson wrote:
> I?d have to agree with Bob on this one. We are aware of devices which 
> cannot support CISC, and which would seriously break if presented with 
> it. A change such as this (either a or b) could create havoc with 
> device interoperability.
>
> +Craig
>
> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com> wrote:
>
>     Dave,
>
>     Despite the potential value of CISC to FCP operation in Class 3,
>     we must advise against requiring or even recommending it.
>
>     In our interoperability testing, we have discovered there are
>     devices with significant installed base that do not behave
>     properly when actually presented with CISC. Unfortunately, they do
>     not reject an N_Port Login that offers CISC, so this problem is
>     not discoverable.
>
>     Even recommending CISC in a standard would therefore increase the
>     incidence of interoperability problems with use of Fibre Channel.
>
>     - Bob Nixon, Emulex alternate representative
>
>     -----Original Message-----
>     *From:* t11_3-bounces at listserve.com
>     [mailto:t11_3-bounces at listserve.com]
>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>     *Sent:* Sunday, October 08, 2006 12:34 PM
>     *To:* t10 at t10.org
>     *Cc:* t11_3 at t11.org
>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>
>     Howdy All,
>
>     At the last FCP-4 working group meeting I presented a proposal to
>     request the use of continuously increasing SEQ_CNT (CISC) for
>     Class 3 service.
>
>     While most believe requiring continuously increasing SEQ_CNT for
>     Class 3 service is a good idea, one vendor indicated that none of
>     their implementations support CISC, and another vendor was
>     concerned about the requirement.
>
>     As such, we have the following options:
>
>     a. require CISC for Class 3 service. This means that existing
>     implementations can claim compliance to a prior standard (e.g.,
>     FCP-3);
>     b. specify that CISC should be used for Class 3 service;
>     c. no change (i.e., CISC is not required except for streamed
>     Sequences).
>
>     My preference would be option a.
>
>     What say ye?
>
>     ...Dave
>
>     (no disclaimer)
>
>
>    
------------------------------------------------------------------------
>
>     _______________________________________________
>     T11_3 mailing list
>     http://mailman.listserve.com/listmanager/listinfo/t11_3
>
>
>
> ------------------------------------------------------------------
> Craig W. Carlson mailto:craig.carlson at qlogic.com
> QLogic Corporation (952) 932-4064
> 6321 Bury Drive
> Eden Prairie, MN 55346
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> T11_3 mailing list
> http://mailman.listserve.com/listmanager/listinfo/t11_3
>   
_______________________________________________
T11_3 mailing list
http://mailman.listserve.com/listmanager/listinfo/t11_3


From cds at cisco.com  Fri Nov  3 13:38:08 2006
From: cds at cisco.com (Claudio DeSanti)
Date: Fri, 03 Nov 2006 13:38:08 -0800
Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT
Message-ID: <mailman.929.1441607310.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Claudio DeSanti <cds at cisco.com>
*
Craig, Bob, Dave,
there are functions defined in FCP-4, such as data overlay or certain 
bi-directional commands, that are simply not implementable in Class 3 
without the use of CISC. I bet that the devices you are referring to do 
not implement these functions. I recommend to identify these functions 
in FCP-4 and either:
a) obsolete them; or
b) clearly state that use of CISC is required to implement them in Class 3.
In addition, the usage of CISC greatly simplifies error recovery in 
Class 3. We should encourage this behavior moving forward. I recommend 
that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but 
not its use. CISC should be mandatory to support and optional to use in 
FCP-4. In this way we set a good path for the future, while allowing 
complete interoperability with FCP-3 and older devices that do not 
support CISC. To ease this interoperability FCP-4 may also recommend to 
not use CISC by default. But mandating its support in FCP-4 devices, we 
achieve that when connecting FCP-4 only devices CISC may be turned on 
and used, with all its advantages.
Thanks,
Claudio.
Craig W. Carlson wrote:
> I?d have to agree with Bob on this one. We are aware of devices which 
> cannot support CISC, and which would seriously break if presented with 
> it. A change such as this (either a or b) could create havoc with 
> device interoperability.
>
> +Craig
>
> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com> wrote:
>
>     Dave,
>
>     Despite the potential value of CISC to FCP operation in Class 3,
>     we must advise against requiring or even recommending it.
>
>     In our interoperability testing, we have discovered there are
>     devices with significant installed base that do not behave
>     properly when actually presented with CISC. Unfortunately, they do
>     not reject an N_Port Login that offers CISC, so this problem is
>     not discoverable.
>
>     Even recommending CISC in a standard would therefore increase the
>     incidence of interoperability problems with use of Fibre Channel.
>
>     - Bob Nixon, Emulex alternate representative
>
>     -----Original Message-----
>     *From:* t11_3-bounces at listserve.com
>     [mailto:t11_3-bounces at listserve.com]
>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>     *Sent:* Sunday, October 08, 2006 12:34 PM
>     *To:* t10 at t10.org
>     *Cc:* t11_3 at t11.org
>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>
>     Howdy All,
>
>     At the last FCP-4 working group meeting I presented a proposal to
>     request the use of continuously increasing SEQ_CNT (CISC) for
>     Class 3 service.
>
>     While most believe requiring continuously increasing SEQ_CNT for
>     Class 3 service is a good idea, one vendor indicated that none of
>     their implementations support CISC, and another vendor was
>     concerned about the requirement.
>
>     As such, we have the following options:
>
>     a. require CISC for Class 3 service. This means that existing
>     implementations can claim compliance to a prior standard (e.g.,
>     FCP-3);
>     b. specify that CISC should be used for Class 3 service;
>     c. no change (i.e., CISC is not required except for streamed
>     Sequences).
>
>     My preference would be option a.
>
>     What say ye?
>
>     ...Dave
>
>     (no disclaimer)
>
>
>    
------------------------------------------------------------------------
>
>     _______________________________________________
>     T11_3 mailing list
>     http://mailman.listserve.com/listmanager/listinfo/t11_3
>
>
>
> ------------------------------------------------------------------
> Craig W. Carlson mailto:craig.carlson at qlogic.com
> QLogic Corporation (952) 932-4064
> 6321 Bury Drive
> Eden Prairie, MN 55346
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> T11_3 mailing list
> http://mailman.listserve.com/listmanager/listinfo/t11_3
>   
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Sat Nov  4 23:03:51 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 5 Nov 2006 00:03:51 -0700
Subject: Recent T10 documents uploaded since 2006/10/29
Message-ID: <mailman.930.1441607310.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPC-4: Log Command Corrections
(by: George O. Penokie)
T10/05-232r2   Uploaded: 2006/11/01   52400 bytes
ftp://ftp.t10.org/t10/document.05/05-232r2.pdf
ADT-2 Negotiable Time-Outs
(by: Michael Banther)
T10/05-377r2   Uploaded: 2006/11/01   129439 bytes
ftp://ftp.t10.org/t10/document.05/05-377r2.pdf
SMC-3 New Additional Sense Codes for Media Changers
(by: Rod Wideman)
T10/06-110r0   Uploaded: 2006/10/31   107395 bytes
ftp://ftp.t10.org/t10/document.06/06-110r0.pdf
Minutes: ADI Meeting (10 July 2006)
(by: Michael Banther)
T10/06-306r2   Uploaded: 2006/10/30   29958 bytes
ftp://ftp.t10.org/t10/document.06/06-306r2.pdf
SAS-2 Response to abandon-class OPEN_REJECT
(by: Rob Elliott)
T10/06-322r2   Uploaded: 2006/10/30   89017 bytes
ftp://ftp.t10.org/t10/document.06/06-322r2.pdf
SAS-2 Modifications to the SAS Speed Negotiation
(by: Stephen Finch, Amr Wassal)
T10/06-324r7   Uploaded: 2006/10/30   439587 bytes
ftp://ftp.t10.org/t10/document.06/06-324r7.pdf
SAS-2 Modifications to the SAS Speed Negotiation
(by: Stephen Finch, Amr Wassal)
T10/06-324r8   Uploaded: 2006/11/02   433606 bytes
ftp://ftp.t10.org/t10/document.06/06-324r8.pdf
SPC-4: Establishing a Security Association using IKEv2
(by: Matt Ball & David Black)
T10/06-449r0   Uploaded: 2006/11/03   132686 bytes
ftp://ftp.t10.org/t10/document.06/06-449r0.pdf
SAS-2: SAM-4: Miscellaneous State Machine Fixes
(by: George O. Penokie)
T10/06-451r2   Uploaded: 2006/11/03   469222 bytes
ftp://ftp.t10.org/t10/document.06/06-451r2.pdf
SMC-3 Medium type codes
(by: Noud Snelder)
T10/06-452r1   Uploaded: 2006/10/31   11896 bytes
ftp://ftp.t10.org/t10/document.06/06-452r1.pdf
SMC-3 Support column in mode page codes and subpage codes table
(by: Noud Snelder)
T10/06-456r0   Uploaded: 2006/10/31   13816 bytes
ftp://ftp.t10.org/t10/document.06/06-456r0.pdf
SAS-2 OOB transmission requirements
(by: Alvin Cox)
T10/06-463r1   Uploaded: 2006/11/01   53214 bytes
ftp://ftp.t10.org/t10/document.06/06-463r1.pdf
SAS-2 OOB transmission requirements
(by: Alvin Cox)
T10/06-463r2   Uploaded: 2006/11/02   54350 bytes
ftp://ftp.t10.org/t10/document.06/06-463r2.pdf
Minutes of SAS PHY Working Group teleconference Oct 26, 2006
(by: Alvin Cox)
T10/06-469r0   Uploaded: 2006/10/30   21210 bytes
ftp://ftp.t10.org/t10/document.06/06-469r0.pdf
SAS-2: Transport layer read data flowchart
(by: George O. Penokie)
T10/06-470r1   Uploaded: 2006/11/01   118300 bytes
ftp://ftp.t10.org/t10/document.06/06-470r1.pdf
ADC-2 Letter Ballot Comment Resolution
(by: Paul Entzel)
T10/06-475r0   Uploaded: 2006/10/31   156612 bytes
ftp://ftp.t10.org/t10/document.06/06-475r0.pdf
SAS-2 DISCOVER response Attached Device Name for SATA
(by: Rob Elliott)
T10/06-476r0   Uploaded: 2006/10/31   35988 bytes
ftp://ftp.t10.org/t10/document.06/06-476r0.pdf
SMC-3 Command table and INQUIRY clean-up
(by: Michael Banther)
T10/06-477r0   Uploaded: 2006/11/01   84067 bytes
ftp://ftp.t10.org/t10/document.06/06-477r0.pdf
SAS-2 Changes to NEGOTIATED PHYSICAL LINK RATE
(by: Brian Day)
T10/06-478r0   Uploaded: 2006/11/01   167948 bytes
ftp://ftp.t10.org/t10/document.06/06-478r0.pdf
SBC-3 Mandate CAPACITY DATA HAS CHANGED unit attention
(by: Rob Elliott)
T10/06-479r0   Uploaded: 2006/11/01   12606 bytes
ftp://ftp.t10.org/t10/document.06/06-479r0.pdf
IR Status Report for November 2007
(by: Gary S. Robinson)
T10/06-480r0   Uploaded: 2006/11/02   22445 bytes
ftp://ftp.t10.org/t10/document.06/06-480r0.pdf
Minutes of SAS PHY Working Group teleconference Nov 2, 2006
(by: Alvin Cox)
T10/06-481r0   Uploaded: 2006/11/02   16818 bytes
ftp://ftp.t10.org/t10/document.06/06-481r0.pdf
SAS-2: Transport layer initiator read data flowchart
(by: George O. Penokie)
T10/06-489r0   Uploaded: 2006/11/03   75632 bytes
ftp://ftp.t10.org/t10/document.06/06-489r0.pdf
Working Drafts
--------------
Automation/Drive Interface - Commands - 2 (ADC-2)
(Editor: Paul Entzel)
 Rev: 07a      Uploaded: 2006/10/31   728047 bytes
ftp://ftp.t10.org/t10/drafts/adc2/adc2r07a.pdf
Fibre Channel Protocol - 4 (FCP-4)
(Editor: Dave Peterson)
 Rev: 00a      Uploaded: 2006/10/30   874594 bytes
ftp://ftp.t10.org/t10/drafts/fcp4/fcp4r00a.pdf
SCSI Stream Commands - 3 (SSC-3)
(Editor: Dave Peterson)
 Rev: 03b      Uploaded: 2006/10/30   1147596 bytes
ftp://ftp.t10.org/t10/drafts/ssc3/ssc3r03b.pdf
(Report generated on 2006/11/05 at 00:03:50)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Black_David at emc.com  Sun Nov  5 22:48:24 2006
From: Black_David at emc.com (Black_David at emc.com)
Date: Mon, 6 Nov 2006 01:48:24 -0500
Subject: SPC-4: 06-449r0 "Establishing a Security Association using IKEv2" now available
Message-ID: <mailman.931.1441607310.22510.t10@sandbox.t10.org>

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

Slides that explain (some) of what's going on in 06-449r0 and
related proposals are now available as 06-492r0.  Both Matt
and I will be in Las Vegas on Tuesday.
Thanks,
--David
________________________________
	From: Matt Ball [mailto:matt.ball at quantum.com] 
	Sent: Friday, November 03, 2006 10:43 AM
	To: T10 Reflector
	Cc: Black, David
	Subject: SPC-4: 06-449r0 "Establishing a Security Association
using IKEv2" now available
	Hi All,
	Just a quick heads-up: David Black and I have posted 06-449r0 to
the T10 website.  See document at:
	<http://www.t10.org/ftp/t10/document.06/06-449r0.pdf&gt;
	This proposal describes a method for creating a 'security
association' (SA) over SCSI.  An SA allows encryption of traffic, such
as encryption keys, over the interface.  If you are interested in
security-related proposals, please take a look and let David and me know
if you have any questions or comments.
	Thanks,
	-Matt


From Jim.Coomes at seagate.com  Mon Nov  6 13:52:23 2006
From: Jim.Coomes at seagate.com (Jim.Coomes at seagate.com)
Date: Mon, 6 Nov 2006 15:52:23 -0600
Subject: [T11.3] FCP-4: Continuously Increasing SEQ_CNT
Message-ID: <mailman.932.1441607310.22510.t10@sandbox.t10.org>

There is Continuously Increasing SEQ_CNT and there is Continuously
Increasing SEQ_CNT. FS-x mandates Continuously Increasing SEQ_CNT within
Sequences and across streamed Sequences. The other Continuously Increasing
SEQ_CNT is established at port login and is Continuously Increasing SEQ_CNT
across the whole Exchange.
As SCSI FCP is basically an interlock protocol, what is the gain in
Exchange Continuously Increasing SEQ_CNT for error detection? If the
command is lost, there is no response from the target. The host has to
time-out. If a write data frame is lost, it is detected by relative offset
or SEQ_CNTat the target. If a transfer ready is lost, the host or the
target has to time-out. If a read data frame is lost, it is detected by
relative offset or SEQ_CNT at the host. If the ending response is lost, the
host has to time-out.
These detection scenarios apply to bidirectional commands also.
Exchange Continuously Increasing SEQ_CNT does not change this behavior.
What is the gain in using Exchange Continuously Increasing SEQ_CNT?
FC has a large installed base of which many devices do not support Exchange
Continuously Increasing SEQ_CNT. This would support not making Exchange
Continuously Increasing SEQ_CNT mandatory in FCP-4. It would also be a
warning that it could be a time delay before Exchange Continuously
Increasing SEQ_CNT could be available widely.
Jim
----- Forwarded by Jim Coomes/Seagate on 11/06/2006 03:13 PM -----
	     Claudio DeSanti						   
	     <cds at cisco.com>						   
	     Sent by:							To 
	     owner-t10 at t10.org	       "Craig W. Carlson"		   
	     No Phone Info	       <craig.carlson at qlogic.com>	   
	     Available							cc 
				       Bob.Nixon at Emulex.Com,		   
				       David.Peterson at mcdata.com, T10	   
	     11/03/2006 03:38	       <t10 at t10.org>			   
	     PM 						   Subject 
				       Re: [T11.3] FCP-4: Continuously	   
				       Increasing SEQ_CNT		   
* From the T10 Reflector (t10 at t10.org), posted by:
* Claudio DeSanti <cds at cisco.com>
*
Craig, Bob, Dave,
there are functions defined in FCP-4, such as data overlay or certain
bi-directional commands, that are simply not implementable in Class 3
without the use of CISC. I bet that the devices you are referring to do
not implement these functions. I recommend to identify these functions
in FCP-4 and either:
a) obsolete them; or
b) clearly state that use of CISC is required to implement them in Class 3.
In addition, the usage of CISC greatly simplifies error recovery in
Class 3. We should encourage this behavior moving forward. I recommend
that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but
not its use. CISC should be mandatory to support and optional to use in
FCP-4. In this way we set a good path for the future, while allowing
complete interoperability with FCP-3 and older devices that do not
support CISC. To ease this interoperability FCP-4 may also recommend to
not use CISC by default. But mandating its support in FCP-4 devices, we
achieve that when connecting FCP-4 only devices CISC may be turned on
and used, with all its advantages.
Thanks,
Claudio.
Craig W. Carlson wrote:
> I???d have to agree with Bob on this one. We are aware of devices which
> cannot support CISC, and which would seriously break if presented with
> it. A change such as this (either a or b) could create havoc with
> device interoperability.
>
> +Craig
>
> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com> wrote:
>
>     Dave,
>
>     Despite the potential value of CISC to FCP operation in Class 3,
>     we must advise against requiring or even recommending it.
>
>     In our interoperability testing, we have discovered there are
>     devices with significant installed base that do not behave
>     properly when actually presented with CISC. Unfortunately, they do
>     not reject an N_Port Login that offers CISC, so this problem is
>     not discoverable.
>
>     Even recommending CISC in a standard would therefore increase the
>     incidence of interoperability problems with use of Fibre Channel.
>
>     - Bob Nixon, Emulex alternate representative
>
>     -----Original Message-----
>     *From:* t11_3-bounces at listserve.com
>     [mailto:t11_3-bounces at listserve.com]
>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>     *Sent:* Sunday, October 08, 2006 12:34 PM
>     *To:* t10 at t10.org
>     *Cc:* t11_3 at t11.org
>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>
>     Howdy All,
>
>     At the last FCP-4 working group meeting I presented a proposal to
>     request the use of continuously increasing SEQ_CNT (CISC) for
>     Class 3 service.
>
>     While most believe requiring continuously increasing SEQ_CNT for
>     Class 3 service is a good idea, one vendor indicated that none of
>     their implementations support CISC, and another vendor was
>     concerned about the requirement.
>
>     As such, we have the following options:
>
>     a. require CISC for Class 3 service. This means that existing
>     implementations can claim compliance to a prior standard (e.g.,
>     FCP-3);
>     b. specify that CISC should be used for Class 3 service;
>     c. no change (i.e., CISC is not required except for streamed
>     Sequences).
>
>     My preference would be option a.
>
>     What say ye?
>
>     ...Dave
>
>     (no disclaimer)
>
>
>
------------------------------------------------------------------------
>
>     _______________________________________________
>     T11_3 mailing list
>     http://mailman.listserve.com/listmanager/listinfo/t11_3
>
>
>
> ------------------------------------------------------------------
> Craig W. Carlson mailto:craig.carlson at qlogic.com
> QLogic Corporation (952) 932-4064
> 6321 Bury Drive
> Eden Prairie, MN 55346
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> T11_3 mailing list
> http://mailman.listserve.com/listmanager/listinfo/t11_3
>
*
* For T10 Reflector information, send a message with


From Jim.Coomes at seagate.com  Mon Nov  6 13:52:23 2006
From: Jim.Coomes at seagate.com (Jim.Coomes at seagate.com)
Date: Mon, 6 Nov 2006 15:52:23 -0600
Subject: FCP-4: Continuously Increasing SEQ_CNT
Message-ID: <mailman.933.1441607310.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Jim.Coomes at seagate.com
*
There is Continuously Increasing SEQ_CNT and there is Continuously
Increasing SEQ_CNT. FS-x mandates Continuously Increasing SEQ_CNT within
Sequences and across streamed Sequences. The other Continuously Increasing
SEQ_CNT is established at port login and is Continuously Increasing SEQ_CNT
across the whole Exchange.
As SCSI FCP is basically an interlock protocol, what is the gain in
Exchange Continuously Increasing SEQ_CNT for error detection? If the
command is lost, there is no response from the target. The host has to
time-out. If a write data frame is lost, it is detected by relative offset
or SEQ_CNTat the target. If a transfer ready is lost, the host or the
target has to time-out. If a read data frame is lost, it is detected by
relative offset or SEQ_CNT at the host. If the ending response is lost, the
host has to time-out.
These detection scenarios apply to bidirectional commands also.
Exchange Continuously Increasing SEQ_CNT does not change this behavior.
What is the gain in using Exchange Continuously Increasing SEQ_CNT?
FC has a large installed base of which many devices do not support Exchange
Continuously Increasing SEQ_CNT. This would support not making Exchange
Continuously Increasing SEQ_CNT mandatory in FCP-4. It would also be a
warning that it could be a time delay before Exchange Continuously
Increasing SEQ_CNT could be available widely.
Jim
----- Forwarded by Jim Coomes/Seagate on 11/06/2006 03:13 PM -----
	     Claudio DeSanti						   
	     <cds at cisco.com>						   
	     Sent by:							To 
	     owner-t10 at t10.org	       "Craig W. Carlson"		   
	     No Phone Info	       <craig.carlson at qlogic.com>	   
	     Available							cc 
				       Bob.Nixon at Emulex.Com,		   
				       David.Peterson at mcdata.com, T10	   
	     11/03/2006 03:38	       <t10 at t10.org>			   
	     PM 						   Subject 
				       Re: [T11.3] FCP-4: Continuously	   
				       Increasing SEQ_CNT		   
* From the T10 Reflector (t10 at t10.org), posted by:
* Claudio DeSanti <cds at cisco.com>
*
Craig, Bob, Dave,
there are functions defined in FCP-4, such as data overlay or certain
bi-directional commands, that are simply not implementable in Class 3
without the use of CISC. I bet that the devices you are referring to do
not implement these functions. I recommend to identify these functions
in FCP-4 and either:
a) obsolete them; or
b) clearly state that use of CISC is required to implement them in Class 3.
In addition, the usage of CISC greatly simplifies error recovery in
Class 3. We should encourage this behavior moving forward. I recommend
that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but
not its use. CISC should be mandatory to support and optional to use in
FCP-4. In this way we set a good path for the future, while allowing
complete interoperability with FCP-3 and older devices that do not
support CISC. To ease this interoperability FCP-4 may also recommend to
not use CISC by default. But mandating its support in FCP-4 devices, we
achieve that when connecting FCP-4 only devices CISC may be turned on
and used, with all its advantages.
Thanks,
Claudio.
Craig W. Carlson wrote:
> I???d have to agree with Bob on this one. We are aware of devices which
> cannot support CISC, and which would seriously break if presented with
> it. A change such as this (either a or b) could create havoc with
> device interoperability.
>
> +Craig
>
> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com> wrote:
>
>     Dave,
>
>     Despite the potential value of CISC to FCP operation in Class 3,
>     we must advise against requiring or even recommending it.
>
>     In our interoperability testing, we have discovered there are
>     devices with significant installed base that do not behave
>     properly when actually presented with CISC. Unfortunately, they do
>     not reject an N_Port Login that offers CISC, so this problem is
>     not discoverable.
>
>     Even recommending CISC in a standard would therefore increase the
>     incidence of interoperability problems with use of Fibre Channel.
>
>     - Bob Nixon, Emulex alternate representative
>
>     -----Original Message-----
>     *From:* t11_3-bounces at listserve.com
>     [mailto:t11_3-bounces at listserve.com]
>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>     *Sent:* Sunday, October 08, 2006 12:34 PM
>     *To:* t10 at t10.org
>     *Cc:* t11_3 at t11.org
>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>
>     Howdy All,
>
>     At the last FCP-4 working group meeting I presented a proposal to
>     request the use of continuously increasing SEQ_CNT (CISC) for
>     Class 3 service.
>
>     While most believe requiring continuously increasing SEQ_CNT for
>     Class 3 service is a good idea, one vendor indicated that none of
>     their implementations support CISC, and another vendor was
>     concerned about the requirement.
>
>     As such, we have the following options:
>
>     a. require CISC for Class 3 service. This means that existing
>     implementations can claim compliance to a prior standard (e.g.,
>     FCP-3);
>     b. specify that CISC should be used for Class 3 service;
>     c. no change (i.e., CISC is not required except for streamed
>     Sequences).
>
>     My preference would be option a.
>
>     What say ye?
>
>     ...Dave
>
>     (no disclaimer)
>
>
>
------------------------------------------------------------------------
>
>     _______________________________________________
>     T11_3 mailing list
>     http://mailman.listserve.com/listmanager/listinfo/t11_3
>
>
>
> ------------------------------------------------------------------
> Craig W. Carlson mailto:craig.carlson at qlogic.com
> QLogic Corporation (952) 932-4064
> 6321 Bury Drive
> Eden Prairie, MN 55346
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> T11_3 mailing list
> http://mailman.listserve.com/listmanager/listinfo/t11_3
>
*
* 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 michael.banther at hp.com  Tue Nov  7 11:11:41 2006
From: michael.banther at hp.com (Banther, Michael)
Date: Tue, 7 Nov 2006 19:11:41 -0000
Subject: ADI Meeting Minutes for November, 2006
Message-ID: <mailman.934.1441607310.22510.t10@sandbox.t10.org>

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

Shortly you will find the minutes for the ADI-2 working group meeting of
6 November 2006 in the T10 document archive at 
http://www.t10.org/ftp/t10/document.06/06-490r0.pdf.
Regards,
Michael Banther
Hewlett-Packard Company
Tel. +44 117 312 9503


From lohmeyer at t10.org  Tue Nov  7 14:45:45 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 07 Nov 2006 15:45:45 -0700
Subject: SAS Protocol WG Minutes posted
Message-ID: <mailman.935.1441607310.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft minutes of the SAS Protocol Working Group are available at:
  http://www.t10.org/ftp/t10/document.06/06-485r0.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 kev at bri.hp.com  Wed Nov  8 00:13:24 2006
From: kev at bri.hp.com (Kevin Jones)
Date: Wed, 08 Nov 2006 08:13:24 -0000
Subject: [T11.3] Re: FCP-4: Continuously Increasing SEQ_CNT
Message-ID: <mailman.936.1441607310.22510.t10@sandbox.t10.org>

My guess at the problem being addressed is the case of an entire
READ DATA SEQUENCE being lost.
eg. a 17KByte read might consist of 2 sequences:
1st sequence = 8*2K frames
2nd sequence = 1*1K frame, which might be lost.
In systems which use only SEQ_CNT for reassembly
(see FC-FS 19.6 "Reassembly Rules") there is a risk of data loss.
In a system is using RELATIVE OFFSET for reassembly then,
as you indicated, a dropped read sequence would be detected
via relative offset (in this case, final relative offset +
final payload size != FCP_CMD.FCP_DL).
Hence, if
PLOGI->N Port Service Parameters->Common Service Parameters->Common
Features->Continuously Increasing Offset == 1
then I see no requirement that SEQ_CNT be set.
The SEQ_CNT proposal seems to be a major change. My perspective
is that reliable class 3 reassembly is done using relative offsets.
Kevin Jones
kevin.jones at hp.com
On Mon, 06 Nov 2006 21:52:23 -0000, <Jim.Coomes at seagate.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Jim.Coomes at seagate.com
> *
>
> There is Continuously Increasing SEQ_CNT and there is Continuously
> Increasing SEQ_CNT. FS-x mandates Continuously Increasing SEQ_CNT within
> Sequences and across streamed Sequences. The other Continuously Increasing
> SEQ_CNT is established at port login and is Continuously Increasing SEQ_CNT
> across the whole Exchange.
>
> As SCSI FCP is basically an interlock protocol, what is the gain in
> Exchange Continuously Increasing SEQ_CNT for error detection? If the
> command is lost, there is no response from the target. The host has to
> time-out. If a write data frame is lost, it is detected by relative offset
> or SEQ_CNTat the target. If a transfer ready is lost, the host or the
> target has to time-out. If a read data frame is lost, it is detected by
> relative offset or SEQ_CNT at the host. If the ending response is lost, the
> host has to time-out.
>
> These detection scenarios apply to bidirectional commands also.
>
> Exchange Continuously Increasing SEQ_CNT does not change this behavior.
> What is the gain in using Exchange Continuously Increasing SEQ_CNT?
>
> FC has a large installed base of which many devices do not support Exchange
> Continuously Increasing SEQ_CNT. This would support not making Exchange
> Continuously Increasing SEQ_CNT mandatory in FCP-4. It would also be a
> warning that it could be a time delay before Exchange Continuously
> Increasing SEQ_CNT could be available widely.
>
> Jim
> ----- Forwarded by Jim Coomes/Seagate on 11/06/2006 03:13 PM -----
>	      Claudio DeSanti
>	       <cds at cisco.com>
>	       Sent by: 						  To
>	       owner-t10 at t10.org	 "Craig W. Carlson"
>	       No Phone Info		 <craig.carlson at qlogic.com>
>	       Available						  cc
>					 Bob.Nixon at Emulex.Com,
>					 David.Peterson at mcdata.com, T10
>	       11/03/2006 03:38 	 <t10 at t10.org>
>	       PM						     Subject
>					 Re: [T11.3] FCP-4: Continuously
>					 Increasing SEQ_CNT
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Claudio DeSanti <cds at cisco.com>
> *
> Craig, Bob, Dave,
>
> there are functions defined in FCP-4, such as data overlay or certain
> bi-directional commands, that are simply not implementable in Class 3
> without the use of CISC. I bet that the devices you are referring to do
> not implement these functions. I recommend to identify these functions
> in FCP-4 and either:
> a) obsolete them; or
> b) clearly state that use of CISC is required to implement them in Class 3.
>
> In addition, the usage of CISC greatly simplifies error recovery in
> Class 3. We should encourage this behavior moving forward. I recommend
> that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but
> not its use. CISC should be mandatory to support and optional to use in
> FCP-4. In this way we set a good path for the future, while allowing
> complete interoperability with FCP-3 and older devices that do not
> support CISC. To ease this interoperability FCP-4 may also recommend to
> not use CISC by default. But mandating its support in FCP-4 devices, we
> achieve that when connecting FCP-4 only devices CISC may be turned on
> and used, with all its advantages.
>
> Thanks,
>
> Claudio.
>
>
> Craig W. Carlson wrote:
>> I???d have to agree with Bob on this one. We are aware of devices which
>> cannot support CISC, and which would seriously break if presented with
>> it. A change such as this (either a or b) could create havoc with
>> device interoperability.
>>
>> +Craig
>>
>> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com> wrote:
>>
>>     Dave,
>>
>>     Despite the potential value of CISC to FCP operation in Class 3,
>>     we must advise against requiring or even recommending it.
>>
>>     In our interoperability testing, we have discovered there are
>>     devices with significant installed base that do not behave
>>     properly when actually presented with CISC. Unfortunately, they do
>>     not reject an N_Port Login that offers CISC, so this problem is
>>     not discoverable.
>>
>>     Even recommending CISC in a standard would therefore increase the
>>     incidence of interoperability problems with use of Fibre Channel.
>>
>>     - Bob Nixon, Emulex alternate representative
>>
>>     -----Original Message-----
>>     *From:* t11_3-bounces at listserve.com
>>     [mailto:t11_3-bounces at listserve.com]
>>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>>     *Sent:* Sunday, October 08, 2006 12:34 PM
>>     *To:* t10 at t10.org
>>     *Cc:* t11_3 at t11.org
>>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>>
>>     Howdy All,
>>
>>     At the last FCP-4 working group meeting I presented a proposal to
>>     request the use of continuously increasing SEQ_CNT (CISC) for
>>     Class 3 service.
>>
>>     While most believe requiring continuously increasing SEQ_CNT for
>>     Class 3 service is a good idea, one vendor indicated that none of
>>     their implementations support CISC, and another vendor was
>>     concerned about the requirement.
>>
>>     As such, we have the following options:
>>
>>     a. require CISC for Class 3 service. This means that existing
>>     implementations can claim compliance to a prior standard (e.g.,
>>     FCP-3);
>>     b. specify that CISC should be used for Class 3 service;
>>     c. no change (i.e., CISC is not required except for streamed
>>     Sequences).
>>
>>     My preference would be option a.
>>
>>     What say ye?
>>
>>     ...Dave
>>
>>     (no disclaimer)
>>
>>
>>
> ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     T11_3 mailing list
>>     http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>>
>>
>> ------------------------------------------------------------------
>> Craig W. Carlson mailto:craig.carlson at qlogic.com
>> QLogic Corporation (952) 932-4064
>> 6321 Bury Drive
>> Eden Prairie, MN 55346
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> T11_3 mailing list
>> http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>
>
> *
> * 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
>
>
_______________________________________________
T11_3 mailing list
http://mailman.listserve.com/listmanager/listinfo/t11_3


From Alvin.Cox at seagate.com  Tue Nov  7 22:58:40 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 8 Nov 2006 00:58:40 -0600
Subject: SAS PHY working group minutes posted
Message-ID: <mailman.937.1441607310.22510.t10@sandbox.t10.org>

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

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


From kev at bri.hp.com  Wed Nov  8 00:13:24 2006
From: kev at bri.hp.com (Kevin Jones)
Date: Wed, 08 Nov 2006 08:13:24 -0000
Subject: FCP-4: Continuously Increasing SEQ_CNT
Message-ID: <mailman.938.1441607310.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Kevin Jones" <kev at bri.hp.com>
*
My guess at the problem being addressed is the case of an entire
READ DATA SEQUENCE being lost.
eg. a 17KByte read might consist of 2 sequences:
1st sequence = 8*2K frames
2nd sequence = 1*1K frame, which might be lost.
In systems which use only SEQ_CNT for reassembly
(see FC-FS 19.6 "Reassembly Rules") there is a risk of data loss.
In a system is using RELATIVE OFFSET for reassembly then,
as you indicated, a dropped read sequence would be detected
via relative offset (in this case, final relative offset +
final payload size != FCP_CMD.FCP_DL).
Hence, if
PLOGI->N Port Service Parameters->Common Service Parameters->Common
Features->Continuously Increasing Offset == 1
then I see no requirement that SEQ_CNT be set.
The SEQ_CNT proposal seems to be a major change. My perspective
is that reliable class 3 reassembly is done using relative offsets.
Kevin Jones
kevin.jones at hp.com
On Mon, 06 Nov 2006 21:52:23 -0000, <Jim.Coomes at seagate.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Jim.Coomes at seagate.com
> *
>
> There is Continuously Increasing SEQ_CNT and there is Continuously
> Increasing SEQ_CNT. FS-x mandates Continuously Increasing SEQ_CNT within
> Sequences and across streamed Sequences. The other Continuously Increasing
> SEQ_CNT is established at port login and is Continuously Increasing SEQ_CNT
> across the whole Exchange.
>
> As SCSI FCP is basically an interlock protocol, what is the gain in
> Exchange Continuously Increasing SEQ_CNT for error detection? If the
> command is lost, there is no response from the target. The host has to
> time-out. If a write data frame is lost, it is detected by relative offset
> or SEQ_CNTat the target. If a transfer ready is lost, the host or the
> target has to time-out. If a read data frame is lost, it is detected by
> relative offset or SEQ_CNT at the host. If the ending response is lost, the
> host has to time-out.
>
> These detection scenarios apply to bidirectional commands also.
>
> Exchange Continuously Increasing SEQ_CNT does not change this behavior.
> What is the gain in using Exchange Continuously Increasing SEQ_CNT?
>
> FC has a large installed base of which many devices do not support Exchange
> Continuously Increasing SEQ_CNT. This would support not making Exchange
> Continuously Increasing SEQ_CNT mandatory in FCP-4. It would also be a
> warning that it could be a time delay before Exchange Continuously
> Increasing SEQ_CNT could be available widely.
>
> Jim
> ----- Forwarded by Jim Coomes/Seagate on 11/06/2006 03:13 PM -----
>	      Claudio DeSanti
>	       <cds at cisco.com>
>	       Sent by: 						  To
>	       owner-t10 at t10.org	 "Craig W. Carlson"
>	       No Phone Info		 <craig.carlson at qlogic.com>
>	       Available						  cc
>					 Bob.Nixon at Emulex.Com,
>					 David.Peterson at mcdata.com, T10
>	       11/03/2006 03:38 	 <t10 at t10.org>
>	       PM						     Subject
>					 Re: [T11.3] FCP-4: Continuously
>					 Increasing SEQ_CNT
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Claudio DeSanti <cds at cisco.com>
> *
> Craig, Bob, Dave,
>
> there are functions defined in FCP-4, such as data overlay or certain
> bi-directional commands, that are simply not implementable in Class 3
> without the use of CISC. I bet that the devices you are referring to do
> not implement these functions. I recommend to identify these functions
> in FCP-4 and either:
> a) obsolete them; or
> b) clearly state that use of CISC is required to implement them in Class 3.
>
> In addition, the usage of CISC greatly simplifies error recovery in
> Class 3. We should encourage this behavior moving forward. I recommend
> that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but
> not its use. CISC should be mandatory to support and optional to use in
> FCP-4. In this way we set a good path for the future, while allowing
> complete interoperability with FCP-3 and older devices that do not
> support CISC. To ease this interoperability FCP-4 may also recommend to
> not use CISC by default. But mandating its support in FCP-4 devices, we
> achieve that when connecting FCP-4 only devices CISC may be turned on
> and used, with all its advantages.
>
> Thanks,
>
> Claudio.
>
>
> Craig W. Carlson wrote:
>> I???d have to agree with Bob on this one. We are aware of devices which
>> cannot support CISC, and which would seriously break if presented with
>> it. A change such as this (either a or b) could create havoc with
>> device interoperability.
>>
>> +Craig
>>
>> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com> wrote:
>>
>>     Dave,
>>
>>     Despite the potential value of CISC to FCP operation in Class 3,
>>     we must advise against requiring or even recommending it.
>>
>>     In our interoperability testing, we have discovered there are
>>     devices with significant installed base that do not behave
>>     properly when actually presented with CISC. Unfortunately, they do
>>     not reject an N_Port Login that offers CISC, so this problem is
>>     not discoverable.
>>
>>     Even recommending CISC in a standard would therefore increase the
>>     incidence of interoperability problems with use of Fibre Channel.
>>
>>     - Bob Nixon, Emulex alternate representative
>>
>>     -----Original Message-----
>>     *From:* t11_3-bounces at listserve.com
>>     [mailto:t11_3-bounces at listserve.com]
>>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>>     *Sent:* Sunday, October 08, 2006 12:34 PM
>>     *To:* t10 at t10.org
>>     *Cc:* t11_3 at t11.org
>>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>>
>>     Howdy All,
>>
>>     At the last FCP-4 working group meeting I presented a proposal to
>>     request the use of continuously increasing SEQ_CNT (CISC) for
>>     Class 3 service.
>>
>>     While most believe requiring continuously increasing SEQ_CNT for
>>     Class 3 service is a good idea, one vendor indicated that none of
>>     their implementations support CISC, and another vendor was
>>     concerned about the requirement.
>>
>>     As such, we have the following options:
>>
>>     a. require CISC for Class 3 service. This means that existing
>>     implementations can claim compliance to a prior standard (e.g.,
>>     FCP-3);
>>     b. specify that CISC should be used for Class 3 service;
>>     c. no change (i.e., CISC is not required except for streamed
>>     Sequences).
>>
>>     My preference would be option a.
>>
>>     What say ye?
>>
>>     ...Dave
>>
>>     (no disclaimer)
>>
>>
>>
> ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     T11_3 mailing list
>>     http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>>
>>
>> ------------------------------------------------------------------
>> Craig W. Carlson mailto:craig.carlson at qlogic.com
>> QLogic Corporation (952) 932-4064
>> 6321 Bury Drive
>> Eden Prairie, MN 55346
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> T11_3 mailing list
>> http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>
>
> *
> * 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 lohmeyer at t10.org  Wed Nov  8 17:02:46 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 08 Nov 2006 18:02:46 -0700
Subject: Fwd: 2nd Call - INCITS/T10 International Representative -
  Closes December  8, 2006
Message-ID: <mailman.939.1441607310.22510.t10@sandbox.t10.org>

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

I understand that Gary Robinson, the current T10 IR, does plan to apply.
However, the second call is open and closes December 8th. -- John
>X-Ninja-PIM: Scanned by Ninja
>X-Ninja-AttachmentFiltering: (no action)
>Subject: 2nd Call - INCITS/T10 International Representative - Closes
December 
>	 8, 2006
>Date: Wed, 8 Nov 2006 11:45:53 -0500
>Thread-Topic: 2nd Call - INCITS/T10 International Representative - Closes
December 8, 2006
>Thread-Index: AccDVVsi4ItHjrhJRPaCxjI7rZ28oA==
>Importance: high
>From: "Garner, Jennifer" <jgarner at itic.org>
>To: John Lohmeyer <lohmeyer at t10.org>,
>	 "Robinson, Gary" 
>	 <g.robinson at computer.org>
>Cc: "Purnell, Parthenia" <ppurnell at itic.org>, "Barra, Lynn"
<lbarra 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: 08 Nov 2006 16:45:37.0882 (UTC)
FILETIME=[518FA3A0:01C70355]
>
>John and Gary 
>
> 
>
>As you may recall, Garys current term as INCITS/T10 International
Representative will expire in March 2007.  The first call for volunteers to
serve as INCITS/T10 IR closed without response on November 6.
>
> 
>
>Please distribute the attached second call to the members of the committee
at your earliest opportunity as it will close on December 8, 2006.
>
> 
>
>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
>
> 
>
> 
>
>in061278
>
>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: November 8, 2006
>Date Due: December 8, 2006
>Replaces:  in061167
>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: SECOND 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 call for volunteers
to serve as International Representative of INCITS/T10 closed without
response on November 6, 2006.
>
>This second call for volunteers to serve as International Representative of
INCITS/T10 is being issued to the members of T10 and will close on December
8, 2006. 
>
>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 December 8, 2006. 
>
> 
>
> 
--
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 Jim.Coomes at seagate.com  Thu Nov  9 07:40:07 2006
From: Jim.Coomes at seagate.com (Jim.Coomes at seagate.com)
Date: Thu, 9 Nov 2006 09:40:07 -0600
Subject: [T11.3] Re: FCP-4: Continuously Increasing SEQ_CNT
Message-ID: <mailman.940.1441607310.22510.t10@sandbox.t10.org>

Kevin,
In the case of a lost read Sequence, The target will send the Response
indicating it has completed the command and the host will detect a transfer
length error. The error does get detected.
Jim
	     "Kevin Jones"						   
	     <kev at bri.hp.com>						   
	     No Phone Info						To 
	     Available		       Jim.Coomes at seagate.com, T10	   
				       <t10 at t10.org>, T11_3		   
				       <t11_3 at t11.org>			   
	     11/08/2006 02:13						cc 
	     AM 							   
								   Subject 
				       Re: FCP-4: Continuously Increasing  
				       SEQ_CNT				   
My guess at the problem being addressed is the case of an entire
READ DATA SEQUENCE being lost.
eg. a 17KByte read might consist of 2 sequences:
1st sequence = 8*2K frames
2nd sequence = 1*1K frame, which might be lost.
In systems which use only SEQ_CNT for reassembly
(see FC-FS 19.6 "Reassembly Rules") there is a risk of data loss.
In a system is using RELATIVE OFFSET for reassembly then,
as you indicated, a dropped read sequence would be detected
via relative offset (in this case, final relative offset +
final payload size != FCP_CMD.FCP_DL).
Hence, if
PLOGI->N Port Service Parameters->Common Service Parameters->Common
Features->Continuously Increasing Offset == 1
then I see no requirement that SEQ_CNT be set.
The SEQ_CNT proposal seems to be a major change. My perspective
is that reliable class 3 reassembly is done using relative offsets.
Kevin Jones
kevin.jones at hp.com
On Mon, 06 Nov 2006 21:52:23 -0000, <Jim.Coomes at seagate.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Jim.Coomes at seagate.com
> *
>
> There is Continuously Increasing SEQ_CNT and there is Continuously
> Increasing SEQ_CNT. FS-x mandates Continuously Increasing SEQ_CNT within
> Sequences and across streamed Sequences. The other Continuously
Increasing
> SEQ_CNT is established at port login and is Continuously Increasing
SEQ_CNT
> across the whole Exchange.
>
> As SCSI FCP is basically an interlock protocol, what is the gain in
> Exchange Continuously Increasing SEQ_CNT for error detection? If the
> command is lost, there is no response from the target. The host has to
> time-out. If a write data frame is lost, it is detected by relative
offset
> or SEQ_CNTat the target. If a transfer ready is lost, the host or the
> target has to time-out. If a read data frame is lost, it is detected by
> relative offset or SEQ_CNT at the host. If the ending response is lost,
the
> host has to time-out.
>
> These detection scenarios apply to bidirectional commands also.
>
> Exchange Continuously Increasing SEQ_CNT does not change this behavior.
> What is the gain in using Exchange Continuously Increasing SEQ_CNT?
>
> FC has a large installed base of which many devices do not support
Exchange
> Continuously Increasing SEQ_CNT. This would support not making Exchange
> Continuously Increasing SEQ_CNT mandatory in FCP-4. It would also be a
> warning that it could be a time delay before Exchange Continuously
> Increasing SEQ_CNT could be available widely.
>
> Jim
> ----- Forwarded by Jim Coomes/Seagate on 11/06/2006 03:13 PM -----
>	      Claudio DeSanti
>	       <cds at cisco.com>
>	       Sent by:
To
>	       owner-t10 at t10.org	 "Craig W. Carlson"
>	       No Phone Info		 <craig.carlson at qlogic.com>
>	       Available
cc
>					 Bob.Nixon at Emulex.Com,
>					 David.Peterson at mcdata.com, T10
>	       11/03/2006 03:38 	 <t10 at t10.org>
>	       PM
Subject
>					 Re: [T11.3] FCP-4: Continuously
>					 Increasing SEQ_CNT
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Claudio DeSanti <cds at cisco.com>
> *
> Craig, Bob, Dave,
>
> there are functions defined in FCP-4, such as data overlay or certain
> bi-directional commands, that are simply not implementable in Class 3
> without the use of CISC. I bet that the devices you are referring to do
> not implement these functions. I recommend to identify these functions
> in FCP-4 and either:
> a) obsolete them; or
> b) clearly state that use of CISC is required to implement them in Class
3.
>
> In addition, the usage of CISC greatly simplifies error recovery in
> Class 3. We should encourage this behavior moving forward. I recommend
> that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but
> not its use. CISC should be mandatory to support and optional to use in
> FCP-4. In this way we set a good path for the future, while allowing
> complete interoperability with FCP-3 and older devices that do not
> support CISC. To ease this interoperability FCP-4 may also recommend to
> not use CISC by default. But mandating its support in FCP-4 devices, we
> achieve that when connecting FCP-4 only devices CISC may be turned on
> and used, with all its advantages.
>
> Thanks,
>
> Claudio.
>
>
> Craig W. Carlson wrote:
>> I???d have to agree with Bob on this one. We are aware of devices which
>> cannot support CISC, and which would seriously break if presented with
>> it. A change such as this (either a or b) could create havoc with
>> device interoperability.
>>
>> +Craig
>>
>> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com>
wrote:
>>
>>     Dave,
>>
>>     Despite the potential value of CISC to FCP operation in Class 3,
>>     we must advise against requiring or even recommending it.
>>
>>     In our interoperability testing, we have discovered there are
>>     devices with significant installed base that do not behave
>>     properly when actually presented with CISC. Unfortunately, they do
>>     not reject an N_Port Login that offers CISC, so this problem is
>>     not discoverable.
>>
>>     Even recommending CISC in a standard would therefore increase the
>>     incidence of interoperability problems with use of Fibre Channel.
>>
>>     - Bob Nixon, Emulex alternate representative
>>
>>     -----Original Message-----
>>     *From:* t11_3-bounces at listserve.com
>>     [mailto:t11_3-bounces at listserve.com]
>>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>>     *Sent:* Sunday, October 08, 2006 12:34 PM
>>     *To:* t10 at t10.org
>>     *Cc:* t11_3 at t11.org
>>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>>
>>     Howdy All,
>>
>>     At the last FCP-4 working group meeting I presented a proposal to
>>     request the use of continuously increasing SEQ_CNT (CISC) for
>>     Class 3 service.
>>
>>     While most believe requiring continuously increasing SEQ_CNT for
>>     Class 3 service is a good idea, one vendor indicated that none of
>>     their implementations support CISC, and another vendor was
>>     concerned about the requirement.
>>
>>     As such, we have the following options:
>>
>>     a. require CISC for Class 3 service. This means that existing
>>     implementations can claim compliance to a prior standard (e.g.,
>>     FCP-3);
>>     b. specify that CISC should be used for Class 3 service;
>>     c. no change (i.e., CISC is not required except for streamed
>>     Sequences).
>>
>>     My preference would be option a.
>>
>>     What say ye?
>>
>>     ...Dave
>>
>>     (no disclaimer)
>>
>>
>>
> ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     T11_3 mailing list
>>     http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>>
>>
>> ------------------------------------------------------------------
>> Craig W. Carlson mailto:craig.carlson at qlogic.com
>> QLogic Corporation (952) 932-4064
>> 6321 Bury Drive
>> Eden Prairie, MN 55346
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> T11_3 mailing list
>> http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>
>
> *
> * 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 Jim.Coomes at seagate.com  Thu Nov  9 07:40:07 2006
From: Jim.Coomes at seagate.com (Jim.Coomes at seagate.com)
Date: Thu, 9 Nov 2006 09:40:07 -0600
Subject: FCP-4: Continuously Increasing SEQ_CNT
Message-ID: <mailman.941.1441607310.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Jim.Coomes at seagate.com
*
Kevin,
In the case of a lost read Sequence, The target will send the Response
indicating it has completed the command and the host will detect a transfer
length error. The error does get detected.
Jim
	     "Kevin Jones"						   
	     <kev at bri.hp.com>						   
	     No Phone Info						To 
	     Available		       Jim.Coomes at seagate.com, T10	   
				       <t10 at t10.org>, T11_3		   
				       <t11_3 at t11.org>			   
	     11/08/2006 02:13						cc 
	     AM 							   
								   Subject 
				       Re: FCP-4: Continuously Increasing  
				       SEQ_CNT				   
My guess at the problem being addressed is the case of an entire
READ DATA SEQUENCE being lost.
eg. a 17KByte read might consist of 2 sequences:
1st sequence = 8*2K frames
2nd sequence = 1*1K frame, which might be lost.
In systems which use only SEQ_CNT for reassembly
(see FC-FS 19.6 "Reassembly Rules") there is a risk of data loss.
In a system is using RELATIVE OFFSET for reassembly then,
as you indicated, a dropped read sequence would be detected
via relative offset (in this case, final relative offset +
final payload size != FCP_CMD.FCP_DL).
Hence, if
PLOGI->N Port Service Parameters->Common Service Parameters->Common
Features->Continuously Increasing Offset == 1
then I see no requirement that SEQ_CNT be set.
The SEQ_CNT proposal seems to be a major change. My perspective
is that reliable class 3 reassembly is done using relative offsets.
Kevin Jones
kevin.jones at hp.com
On Mon, 06 Nov 2006 21:52:23 -0000, <Jim.Coomes at seagate.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Jim.Coomes at seagate.com
> *
>
> There is Continuously Increasing SEQ_CNT and there is Continuously
> Increasing SEQ_CNT. FS-x mandates Continuously Increasing SEQ_CNT within
> Sequences and across streamed Sequences. The other Continuously
Increasing
> SEQ_CNT is established at port login and is Continuously Increasing
SEQ_CNT
> across the whole Exchange.
>
> As SCSI FCP is basically an interlock protocol, what is the gain in
> Exchange Continuously Increasing SEQ_CNT for error detection? If the
> command is lost, there is no response from the target. The host has to
> time-out. If a write data frame is lost, it is detected by relative
offset
> or SEQ_CNTat the target. If a transfer ready is lost, the host or the
> target has to time-out. If a read data frame is lost, it is detected by
> relative offset or SEQ_CNT at the host. If the ending response is lost,
the
> host has to time-out.
>
> These detection scenarios apply to bidirectional commands also.
>
> Exchange Continuously Increasing SEQ_CNT does not change this behavior.
> What is the gain in using Exchange Continuously Increasing SEQ_CNT?
>
> FC has a large installed base of which many devices do not support
Exchange
> Continuously Increasing SEQ_CNT. This would support not making Exchange
> Continuously Increasing SEQ_CNT mandatory in FCP-4. It would also be a
> warning that it could be a time delay before Exchange Continuously
> Increasing SEQ_CNT could be available widely.
>
> Jim
> ----- Forwarded by Jim Coomes/Seagate on 11/06/2006 03:13 PM -----
>	      Claudio DeSanti
>	       <cds at cisco.com>
>	       Sent by:
To
>	       owner-t10 at t10.org	 "Craig W. Carlson"
>	       No Phone Info		 <craig.carlson at qlogic.com>
>	       Available
cc
>					 Bob.Nixon at Emulex.Com,
>					 David.Peterson at mcdata.com, T10
>	       11/03/2006 03:38 	 <t10 at t10.org>
>	       PM
Subject
>					 Re: [T11.3] FCP-4: Continuously
>					 Increasing SEQ_CNT
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Claudio DeSanti <cds at cisco.com>
> *
> Craig, Bob, Dave,
>
> there are functions defined in FCP-4, such as data overlay or certain
> bi-directional commands, that are simply not implementable in Class 3
> without the use of CISC. I bet that the devices you are referring to do
> not implement these functions. I recommend to identify these functions
> in FCP-4 and either:
> a) obsolete them; or
> b) clearly state that use of CISC is required to implement them in Class
3.
>
> In addition, the usage of CISC greatly simplifies error recovery in
> Class 3. We should encourage this behavior moving forward. I recommend
> that FCP-4 mandate the support of CISC to FCP-4 compliant devices, but
> not its use. CISC should be mandatory to support and optional to use in
> FCP-4. In this way we set a good path for the future, while allowing
> complete interoperability with FCP-3 and older devices that do not
> support CISC. To ease this interoperability FCP-4 may also recommend to
> not use CISC by default. But mandating its support in FCP-4 devices, we
> achieve that when connecting FCP-4 only devices CISC may be turned on
> and used, with all its advantages.
>
> Thanks,
>
> Claudio.
>
>
> Craig W. Carlson wrote:
>> I???d have to agree with Bob on this one. We are aware of devices which
>> cannot support CISC, and which would seriously break if presented with
>> it. A change such as this (either a or b) could create havoc with
>> device interoperability.
>>
>> +Craig
>>
>> On 10/13/06 6:08 PM, "Bob.Nixon at Emulex.Com" <Bob.Nixon at Emulex.Com>
wrote:
>>
>>     Dave,
>>
>>     Despite the potential value of CISC to FCP operation in Class 3,
>>     we must advise against requiring or even recommending it.
>>
>>     In our interoperability testing, we have discovered there are
>>     devices with significant installed base that do not behave
>>     properly when actually presented with CISC. Unfortunately, they do
>>     not reject an N_Port Login that offers CISC, so this problem is
>>     not discoverable.
>>
>>     Even recommending CISC in a standard would therefore increase the
>>     incidence of interoperability problems with use of Fibre Channel.
>>
>>     - Bob Nixon, Emulex alternate representative
>>
>>     -----Original Message-----
>>     *From:* t11_3-bounces at listserve.com
>>     [mailto:t11_3-bounces at listserve.com]
>>     <mailto:t11_3-bounces at listserve.com%5D>*On Behalf Of *David Peterson
>>     *Sent:* Sunday, October 08, 2006 12:34 PM
>>     *To:* t10 at t10.org
>>     *Cc:* t11_3 at t11.org
>>     *Subject:* [T11.3] FCP-4: Continuously Increasing SEQ_CNT
>>
>>     Howdy All,
>>
>>     At the last FCP-4 working group meeting I presented a proposal to
>>     request the use of continuously increasing SEQ_CNT (CISC) for
>>     Class 3 service.
>>
>>     While most believe requiring continuously increasing SEQ_CNT for
>>     Class 3 service is a good idea, one vendor indicated that none of
>>     their implementations support CISC, and another vendor was
>>     concerned about the requirement.
>>
>>     As such, we have the following options:
>>
>>     a. require CISC for Class 3 service. This means that existing
>>     implementations can claim compliance to a prior standard (e.g.,
>>     FCP-3);
>>     b. specify that CISC should be used for Class 3 service;
>>     c. no change (i.e., CISC is not required except for streamed
>>     Sequences).
>>
>>     My preference would be option a.
>>
>>     What say ye?
>>
>>     ...Dave
>>
>>     (no disclaimer)
>>
>>
>>
> ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     T11_3 mailing list
>>     http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>>
>>
>> ------------------------------------------------------------------
>> Craig W. Carlson mailto:craig.carlson at qlogic.com
>> QLogic Corporation (952) 932-4064
>> 6321 Bury Drive
>> Eden Prairie, MN 55346
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> T11_3 mailing list
>> http://mailman.listserve.com/listmanager/listinfo/t11_3
>>
>
>
> *
> * 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 mj at feral.com  Thu Nov  9 09:43:38 2006
From: mj at feral.com (Matthew Jacob)
Date: Thu, 9 Nov 2006 09:43:38 -0800 (PST)
Subject: FCP-4: Continuously Increasing SEQ_CNT
Message-ID: <mailman.942.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Matthew Jacob <mj at feral.com>
*
> Kevin,
>
> In the case of a lost read Sequence, The target will send the Response
> indicating it has completed the command and the host will detect a transfer
> length error. The error does get detected.
If, and only if, the target in question is one known to set residual in 
status correctly. Unfortunately, there are a number of targets still out 
there that don't set residual status correctly. This has led to a 
situation where a number of initiator drivers then ignore residual if 
the device type is, say, DIRECT ACCESS and the command isn't one of the 
commands one would expect residuals on.
*
* 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  Thu Nov  9 10:24:27 2006
From: MOverby at nvidia.com (Mark Overby)
Date: Thu, 9 Nov 2006 10:24:27 -0800
Subject: SAT Minutes Posted
Message-ID: <mailman.943.1441607311.22510.t10@sandbox.t10.org>

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

06-486r0
-----------------------------------------------------------------------------
------
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  Thu Nov  9 13:31:31 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 09 Nov 2006 14:31:31 -0700
Subject: CAP WG Minutes posted
Message-ID: <mailman.944.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft CAP working group minutes are available at:
  http://www.t10.org/ftp/t10/document.06/06-487r0.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 steve.finch at st.com  Fri Nov 10 12:57:17 2006
From: steve.finch at st.com (Stephen FINCH)
Date: Fri, 10 Nov 2006 13:57:17 -0700
Subject: SAS-2 Modifications to the SAS Speed Negotiation:  06-324r9 Posted
Message-ID: <mailman.945.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
I have just posted 06-324r9 to T10.
The SAS-2 Phy WG finally completed a full review of this proposal during the
T10 week.  I hope it is now fairly complete.  
I have incorporated all of the suggested changes into revision 9.
I created the newest version without change bars or any of Word's editing
annotations.  
The changed text is either in blue or is noted by editor's comments.  
I feel it is easier to read this way and will make a final review during one
of the upcoming conference calls much easier.
Regards,
Steve Finch
STMicroelectronics
303 381-3587
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Mon Nov 13 15:26:31 2006
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 13 Nov 2006 16:26:31 -0700
Subject: SSC-3: Filemarks/Setmarks and Encryption
Message-ID: <mailman.946.1441607311.22510.t10@sandbox.t10.org>

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

Tapeheads,
I believe that we need to better clarify that Filemarks are "encryption 
neutral".  SSC-3r3b does state in 4.20.2 "Filemarks shall not be 
encrypted" but that is the only statement about filemarks and encryption. 
Additionally there is no statement about setmarks and encryption.
I think we should add the following:
1) In 4.20.2 where it says "Filemarks shall not be encrypted" should be 
changed to "Filemarks and Setmarks shall not be encrypted and are 
considered encryption neutral".
2) In section 4.2.20.3 Reading encrypted data on the medium, the following 
paragraph:
Filemarks and Setmarks are considered encryption neutral.  Reading into a 
Filemark or setmark shall not cause a change of encryption state and shall 
not cause an encryption additional sense code to be returned.
Comments?
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From Alvin.Cox at seagate.com  Tue Nov 14 07:51:04 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Tue, 14 Nov 2006 09:51:04 -0600
Subject: Reminder: SAS PHY WG call, 11/16, 10 am CST
Message-ID: <mailman.947.1441607311.22510.t10@sandbox.t10.org>

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

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
No call on 11/23 or 12/28.
Agenda (more than we can cover):
1. SAS-2 Modifications to the SAS Speed Negotiation 06-324r9 [Finch, 
Wassal]
http://www.t10.org/ftp/t10/document.06/06-324r9.pdf
(Should be a final review of the edited version.)
2. SAS-2 Electrical Specification Proposal 06-496 [Witt]
http://www.t10.org/ftp/t10/document.06/06-496r2.pdf
Page 13 has some interesting questions:
(I would like to concentrate on c and e this call.)
a) SSC Causes Measurement Issues:
??? Tx Jitter Generation
??? Rx Jitter Tolerance
b) Tx De-Emphasis Causes DJ Which Needs to be Removed Before Jitter
Generation Can Be Estimated?
c) Question: Do we Want to Support a Low-Swing Mode for Short / Clean
Channels? Just refer to use SATA 2 level for power saving if desired.
??? 400..600mV
??? No De-Emphasis
(My comment on this is that it is intended for IC-to-IC on a single PCB 
and does not use an existing defined compliance point. The specification 
allows deviation if the connection is not a compliance point, so my 
initial position is that we don't want to do this.)
d) Are We Going to Define a Rx Compliance Channel / Test? Yes we need to.
e) Are we going to support variable or fixed Tx De-Emphasis?
My comments:
??? If fixed, how do we test?
??? The table on page 6 has a -5dB to -7dB range for de-emphasis, but has a 
differential voltage range of 800 min / 1200 max. These seem to be in 
conflict.
??? Mike Jenkins has presented simulations that indicate a fixed de-emphasis 
may not be in the best interest. 
http://www.t10.org/ftp/t10/document.06/06-491r1.pdf
What do we do? Maybe we allow de-emphasis to be used, but bounded by the 
allowed transmitter differential voltage values?
??? Is the external cable application different than the internal 
requirements with regards to de-emphasis requirements?
3. 10-meter cable specification issues
http://www.t10.org/ftp/t10/document.06/06-499r0.pdf
Any updates?
4. EMI considerations for SAS-2
http://www.t10.org/ftp/t10/document.06/06-483r0.pdf
Keep in mind when developing spec.
5. Define a loss for the zero-length test load?
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809
E-Mail	alvin.cox at seagate.com


From raymond_gilson at symantec.com  Tue Nov 14 09:11:41 2006
From: raymond_gilson at symantec.com (Raymond Gilson)
Date: Tue, 14 Nov 2006 11:11:41 -0600
Subject: SSC-3: Filemarks/Setmarks and Encryption
Message-ID: <mailman.948.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Raymond Gilson" <raymond_gilson at symantec.com>
*
I agree, Filemarks must not interact with encryption.
I would also suggest that we be very clear that position operations
(Locate/Space/Rewind) shall work without regard to the encryption state
of the data being positioned over.  We need to move around the media
without being required to provide keys for the data we are passing over.
Thank You,
Raymond Gilson
Symantec Corporation - Mail Stop ROS2-3
2815 Cleveland Avenue, Roseville, MN 55113
Phone: 651.746.7281	Fax: 651.746.6713
E-mail: raymond_gilson at symantec.com
  _____ 
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Monday, November 13, 2006 5:27 PM
	To: t10 at t10.org
	Subject: SSC-3: Filemarks/Setmarks and Encryption
	Tapeheads,
	I believe that we need to better clarify that Filemarks are
"encryption neutral".  SSC-3r3b does state in 4.20.2 "Filemarks shall
not be encrypted" but that is the only statement about filemarks and
encryption.  Additionally there is no statement about setmarks and
encryption.
	I think we should add the following:
	1) In 4.20.2 where it says "Filemarks shall not be encrypted"
should be changed to "Filemarks and Setmarks shall not be encrypted and
are considered encryption neutral".
	2) In section 4.2.20.3 Reading encrypted data on the medium, the
following paragraph:
	Filemarks and Setmarks are considered encryption neutral.
Reading into a Filemark or setmark shall not cause a change of
encryption state and shall not cause an encryption additional sense code
to be returned.
	Comments?
	Thanks,
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-2869 / 520-799-5280
	Fax: 520-799-2723 (T/L:321)
	Email address: kdbutt at us.ibm.com
	http://www-03.ibm.com/servers/storage/
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Rrose at exabyte.com  Tue Nov 14 10:45:05 2006
From: Rrose at exabyte.com (Rose, Roger)
Date: Tue, 14 Nov 2006 11:45:05 -0700
Subject: SSC-3: Filemarks/Setmarks and Encryption
Message-ID: <mailman.949.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Rose, Roger" <Rrose at exabyte.com>
*
As long as this is being addressed for filemarks and setmarks,
End-of-Data should be included.  Space to EOD, then back a few filemarks
is a common operation.
-roger rose
 Exabyte Corp
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Kevin D Butt
> Sent: Monday, November 13, 2006 4:27 PM
> To: t10 at t10.org
> Subject: SSC-3: Filemarks/Setmarks and Encryption
> 
> 
> Tapeheads, 
> 
> I believe that we need to better clarify that Filemarks are 
> "encryption neutral".  SSC-3r3b does state in 4.20.2 
> "Filemarks shall not be encrypted" but that is the only 
> statement about filemarks and encryption.  Additionally there 
> is no statement about setmarks and encryption. 
> 
> I think we should add the following: 
> 1) In 4.20.2 where it says "Filemarks shall not be encrypted" 
> should be changed to "Filemarks and Setmarks shall not be 
> encrypted and are considered encryption neutral". 
> 2) In section 4.2.20.3 Reading encrypted data on the medium, 
> the following paragraph: 
> Filemarks and Setmarks are considered encryption neutral.  
> Reading into a Filemark or setmark shall not cause a change 
> of encryption state and shall not cause an encryption 
> additional sense code to be returned. 
> 
> Comments? 
> 
> Thanks, 
> 
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-2869 / 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/ 
> 
*
* 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 Nov 14 23:13:36 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Wed, 15 Nov 2006 16:13:36 +0900
Subject: Draft Minutes and delivered documents
Message-ID: <mailman.950.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I put draft minutes and delivered documents on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Nov06/
ftp.avc-pioneer.com/Mtfuji_7/Minutes/
The file "Comment on Pioneer.doc" is renamed to "Pio cmnt on MS comments on
DVD-RW DL.doc" to be understandable.
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 geoff.hibbert at finisar.com  Wed Nov 15 18:35:17 2006
From: geoff.hibbert at finisar.com (Geoff Hibbert)
Date: Wed, 15 Nov 2006 18:35:17 -0800
Subject: Concern about Primitive encodings
Message-ID: <mailman.951.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Geoff Hibbert" <geoff.hibbert at finisar.com>
*
Hello,
It appears to me that the Primitive encoding for the BREAK_REPLY
Primitive is identical to the MUX (LOGICAL LINK 1) Primitive (K28.5
D02.0 D29.7 D16.7).
Am I mistaken or is this something that should be addressed?
-Geoffrey Hibbert
-Finisar Corporation
*
* 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 Nov 16 07:06:46 2006
From: gop at us.ibm.com (George Penokie)
Date: Thu, 16 Nov 2006 09:06:46 -0600
Subject: Concern about Primitive encodings
Message-ID: <mailman.952.1441607311.22510.t10@sandbox.t10.org>

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

Geoff,
Any such issue will be fixed when the proposal in incorporated into SAS-2. 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
"Geoff Hibbert" <geoff.hibbert at finisar.com> 
Sent by: owner-t10 at t10.org
11/15/2006 08:35 PM
To
<t10 at t10.org>
cc
Subject
Concern about Primitive encodings
* From the T10 Reflector (t10 at t10.org), posted by:
* "Geoff Hibbert" <geoff.hibbert at finisar.com>
*
Hello,
It appears to me that the Primitive encoding for the BREAK_REPLY
Primitive is identical to the MUX (LOGICAL LINK 1) Primitive (K28.5
D02.0 D29.7 D16.7).
Am I mistaken or is this something that should be addressed?
-Geoffrey Hibbert
-Finisar Corporation
*
* 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  Thu Nov 16 15:01:11 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Thu, 16 Nov 2006 17:01:11 -0600
Subject: SAS-2 revision 7 now available
Message-ID: <mailman.953.1441607311.22510.t10@sandbox.t10.org>

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

Serial Attached SCSI - 2 (SAS-2) revision 7 (sas2r07) is now available
on http://www.t10.org/drafts.htm and http://www.t10.org/new.htm, 
incorporating proposals recommended by the November 2006 T10 plenary
(e.g., multiplexing).
Please review the editor's notes that have accumulated.
The goal for T10 letter ballot is May or July 2007.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


From steve.finch at st.com  Fri Nov 17 07:54:23 2006
From: steve.finch at st.com (Stephen FINCH)
Date: Fri, 17 Nov 2006 08:54:23 -0700
Subject: SAS2:  Speed Negotiation proposal 06-515r0 (formerly 06-423r9) now available
Message-ID: <mailman.954.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
Following the review during the SAS2 Phy conference call yesterday, editorial
updates have been made to 06-324.  We ran out of revision numbers, so a new
document number has been generated.
NO TECHNICAL CHANGES WERE MADE.
It is my belief that we now have the SAS2 speed negotiation process well
defined.  I plan to move to include this information into the SAS2 draft at
the January meetings, so take the time now to review this material.
Regards,
Steve Finch
STMicroelectronics
303 381-3587
Steve.finch at st.com
*
* 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  Fri Nov 17 13:47:59 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Fri, 17 Nov 2006 14:47:59 -0700
Subject: T10 Plenary minutes posted
Message-ID: <mailman.955.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft T10 plenary minutes from November 9th are available at:
  http://www.t10.org/ftp/t10/document.06/06-488r0.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  Sat Nov 18 23:02:12 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 19 Nov 2006 00:02:12 -0700
Subject: Recent T10 documents uploaded since 2006/11/12
Message-ID: <mailman.956.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAS-2: SAM-4: Miscellaneous State Machine Fixes
(by: George O. Penokie)
T10/06-451r3   Uploaded: 2006/11/17   483135 bytes
ftp://ftp.t10.org/t10/document.06/06-451r3.pdf
SAS-2: Transport layer read data flowchart
(by: George O. Penokie)
T10/06-470r2   Uploaded: 2006/11/16   118887 bytes
ftp://ftp.t10.org/t10/document.06/06-470r2.pdf
Minutes of T10 Plenary Meeting #76 - November 9, 2006
(by: Weber & Lohmeyer)
T10/06-488r0   Uploaded: 2006/11/17   51009 bytes
ftp://ftp.t10.org/t10/document.06/06-488r0.htm
Minutes of T10 Plenary Meeting #76 - November 9, 2006
(by: Weber & Lohmeyer)
T10/06-488r0   Uploaded: 2006/11/17   315252 bytes
ftp://ftp.t10.org/t10/document.06/06-488r0.pdf
Minutes of SAS PHY Working Group conference call November 16, 2006
(by: Alvin Cox)
T10/06-514r0   Uploaded: 2006/11/16   33212 bytes
ftp://ftp.t10.org/t10/document.06/06-514r0.pdf
SAS-2 Modifications to the SAS Speed Negotiation
(by: Stephen Finch, Amr Wassal)
T10/06-515r0   Uploaded: 2006/11/16   376226 bytes
ftp://ftp.t10.org/t10/document.06/06-515r0.pdf
SAS-2 Modifications to the SAS Speed Negotiation
(by: Stephen Finch, Amr Wassal)
T10/06-515r0   Uploaded: 2006/11/16   1286887 bytes
ftp://ftp.t10.org/t10/document.06/06-515r0.zip
Working Drafts
--------------
MultiMedia Command Set - 6 (MMC-6)
(Editor: Bill McFerrin)
 Rev: 00       Uploaded: 2006/11/14   4333215 bytes
ftp://ftp.t10.org/t10/drafts/mmc6/mmc6r00.pdf
SCSI Architecture Model - 4 (SAM-4)
(Editor: George Penokie)
 Rev: 08       Uploaded: 2006/11/17   1254857 bytes
ftp://ftp.t10.org/t10/drafts/sam4/sam4r08.pdf
Serial Attached SCSI - 2 (SAS-2)
(Editor: Rob Elliott)
 Rev: 07       Uploaded: 2006/11/16   6512498 bytes
ftp://ftp.t10.org/t10/drafts/sas2/sas2r07.pdf
(Report generated on 2006/11/19 at 00:02:11)
*
* 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  Mon Nov 20 05:28:22 2006
From: michael.banther at hp.com (Banther, Michael)
Date: Mon, 20 Nov 2006 13:28:22 -0000
Subject: SSC-3: Filemarks/Setmarks and Encryption
Message-ID: <mailman.957.1441607311.22510.t10@sandbox.t10.org>

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

Hi Kevin,
I agree that better clarification is a good thing.  I'm not happy with
the term 'encryption neutral'.	Is it defined anywhere?  Exactly what
does it mean?  The second sentence that you propose for 4.2.20.3 is more
to my liking as it says how a device server responds when it encounters
a filemark or setmark.
Regards,
Michael Banther
Hewlett-Packard Ltd.
+44 117 312 9503
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: 13 November 2006 23:27
To: t10 at t10.org
Subject: SSC-3: Filemarks/Setmarks and Encryption
Tapeheads, 
I believe that we need to better clarify that Filemarks are "encryption
neutral".  SSC-3r3b does state in 4.20.2 "Filemarks shall not be
encrypted" but that is the only statement about filemarks and
encryption.  Additionally there is no statement about setmarks and
encryption. 
I think we should add the following: 
1) In 4.20.2 where it says "Filemarks shall not be encrypted" should be
changed to "Filemarks and Setmarks shall not be encrypted and are
considered encryption neutral". 
2) In section 4.2.20.3 Reading encrypted data on the medium, the
following paragraph: 
Filemarks and Setmarks are considered encryption neutral.  Reading into
a Filemark or setmark shall not cause a change of encryption state and
shall not cause an encryption additional sense code to be returned. 
Comments? 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 


From Gary.Franco at Emulex.Com  Mon Nov 20 12:11:23 2006
From: Gary.Franco at Emulex.Com (Gary.Franco at Emulex.Com)
Date: Mon, 20 Nov 2006 12:11:23 -0800
Subject: Differences between WRPROTECT and VRPROTECT
Message-ID: <mailman.958.1441607311.22510.t10@sandbox.t10.org>

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

Is it the specification or my lack of understanding - here is the issue:
Isn't a VERIFY for all intents and purposes the same as a WRITE command
as the DATA is sent to the device for verification.
In a WRITE command if the WRPROTECT bits are 000 (no protection data
available) the target device create its own protection information and
writes it to the disk.
This same operation is not called out for the VERIFY, therefore wouldn't
all the checks fail by default?
__________________________________
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 
Be who you are and say what you feel because those who mind don't matter
and those who matter don't mind.
-Dr. Seuss
This message contains confidential information of Emulex Corporation
intended only for listed recipients and should not be forwarded to
anyone else.  
If you have received this message in error, please delete it
immediately.  Thank you. 


From gop at us.ibm.com  Mon Nov 20 15:21:37 2006
From: gop at us.ibm.com (George Penokie)
Date: Mon, 20 Nov 2006 17:21:37 -0600
Subject: Differences between WRPROTECT and VRPROTECT
Message-ID: <mailman.959.1441607311.22510.t10@sandbox.t10.org>

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

Gary,
There is no data written to the media with a VERIFY command. There is data 
sent to the device that is only to be compared with what is already on the 
media if the BYTCHK bit set to one. In that case the protection 
information moved with the data from the initiator to the target is used 
to check the data that is sent based on the requirements listed in table 
64. The corresponding data is read of the disk and is checked using 
protection information read from the media with the data as defined in 
table 63. Then the data from the initiator and the data read from the 
media is byte checked and the protection information is byte checked as 
defined in table 65.
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
Gary.Franco at Emulex.Com 
Sent by: owner-t10 at t10.org
11/20/2006 02:11 PM
To
<t10 at t10.org>
cc
Subject
Differences between WRPROTECT and VRPROTECT
Is it the specification or my lack of understanding ? here is the issue:
Isn?t a VERIFY for all intents and purposes the same as a WRITE command as 
the DATA is sent to the device for verification.
In a WRITE command if the WRPROTECT bits are 000 (no protection data 
available) the target device create its own protection information and 
writes it to the disk.
This same operation is not called out for the VERIFY, therefore wouldn?t 
all the checks fail by default?
__________________________________
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 
Be who you are and say what you feel because those who mind don't matter 
and those who matter don't mind.
-Dr. Seuss
This message contains confidential information of Emulex Corporation 
intended only for listed recipients and should not be forwarded to anyone 
else. 
If you have received this message in error, please delete it immediately. 
Thank you. 


From Brian.Day at lsi.com  Tue Nov 21 11:21:56 2006
From: Brian.Day at lsi.com (Day, Brian)
Date: Tue, 21 Nov 2006 12:21:56 -0700
Subject: SAS2 Speed Negotiation 06-515 switching between patterns
Message-ID: <mailman.960.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <Brian.Day at lsi.com>
*
So as I interpret this (which is the point of my question), it would be
okay to truncate the both the TRAIN pattern and TRAIN_DONE when
switching to a new pattern due to the state machine changing at
arbitrary points in time.
For example, if SP state is currently in SP29:SAS_Train state and
transmitting the TRAIN pattern, when the conditions to transition to
SP30:SAS_TrainingDone occur at an arbitrary point in time, the SP
transmitter would then switch to sending TRAIN_DONE patterns.  
In other words, there may be less than 58 dwords of random scrambled
data between the TRAIN and TRAIN_DONE primitive sequences.
Actually, there might not be anything preventing the TRAIN primitive
itself from being less than 6 dwords when making this transition... I'm
not sure on this one to be honest.
Same reasoning applies when going from the TrainingDone to PHY_Ready
state.
Is there objection to this type of allowed behavior?  Would that
behavior be okay for the receiver that is still training without messing
up the training algorithm?
I feel this should be allowed behavior from a digital state machine
design standpoint, as it keeps it simple... the actual implementation of
the SP state machine does need to know about the specific dword "state"
of the training pattern.  
Brian Day
LSI Logic
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Stephen
FINCH
Sent: Friday, November 17, 2006 8:54 AM
To: T10 Reflector
Subject: SAS2: Speed Negotiation proposal 06-515r0 (formerly 06-423r9)
now available
* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
Following the review during the SAS2 Phy conference call yesterday,
editorial updates have been made to 06-324.  We ran out of revision
numbers, so a new document number has been generated.
NO TECHNICAL CHANGES WERE MADE.
It is my belief that we now have the SAS2 speed negotiation process well
defined.  I plan to move to include this information into the SAS2 draft
at the January meetings, so take the time now to review this material.
Regards,
Steve Finch
STMicroelectronics
303 381-3587
Steve.finch at st.com
*
* 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 steve.finch at st.com  Tue Nov 21 12:32:57 2006
From: steve.finch at st.com (Stephen FINCH)
Date: Tue, 21 Nov 2006 13:32:57 -0700
Subject: SAS2 Speed Negotiation 06-515 switching between patterns
Message-ID: <mailman.961.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
Brian,
You've made a good point.  It isn't clear.  But I do have an interpretation
that may apply.
My interpretation is that the SP state machine sends a Transmit TRAIN_DONE
pattern message to the SP transmitter, the SP transmitter does the
transmission and generates a TRAIN_DONE Pattern Transmitted when it has
completed the transmission.  It doesn't honor any other transmission
requests until the one it is working on is completed.
The same sequence is true of the Transmit TRAIN pattern, except that the
TRAIN Pattern Transmitted is not received/used within the SP state machine.
Logically, the TRAIN Pattern Transmitted occurs even if it doesn't cause a
message to be sent.
This is implied in other state machines.  A case in point is state
SL_CC4:DisconnectWait state.  Upon entry, it sends a Transmit CLOSE (Normal)
message or Transmit CLOSE (Clear Affiliation) message to the SL transmitter.
Transition SL_CC4:DisconnectWait to SL_CC0:Idle is described as:
"This transition shall occur after:
a) sending a Transmit CLOSE message to the SL transmitter;
b) receiving a CLOSE Received message; and
c) sending a Connection Closed (Normal) confirmation to the port layer."
Note that it doesn't wait for a CLOSE Transmitted message from the SL
transmitter.  The CLOSE is a triple, so the receiving of a CLOSE Received
message could occur before the transmitter has completed send the requested
CLOSE.	We know that the outgoing CLOSE must be sent in its entirety or else
we would be getting CLOSE timeouts frequently. 
I have always interpreted these sequences in the state machines such that,
once a transmitter starts working on a Transmit xxxx message, it completes
that transmission BEFORE it starts on any new transmission.
If this interpretation is right, then the transmitter, in response to a
request to Transmit TRAIN pattern or Transmit TRAIN_DONE pattern, would
always send a complete pattern before honoring a new Transmit xxxxx message.
So, the transition from SP29:SAS_Train state to SP30:SAS_TrainingDone state
can occur in the middle of the transmission of a TRAIN pattern, but the
transmitter would complete the transmission of the TRAIN pattern that it
started in response to the Transmit TRAIN pattern request of SP29, and then
look at the Transmit TRAIN_DONE pattern from SP30 and do that next.
Again, this is my interpretation.  
Are there any other comments???  Agreements??? Disagreements???
Steve Finch
STMicroelectronics
303 381-3587
-----Original Message-----
From: Day, Brian [mailto:Brian.Day at lsi.com] 
Sent: Tuesday, November 21, 2006 12:22 PM
To: Stephen FINCH; T10 Reflector
Subject: SAS2 Speed Negotiation 06-515 switching between patterns
So as I interpret this (which is the point of my question), it would be okay
to truncate the both the TRAIN pattern and TRAIN_DONE when switching to a
new pattern due to the state machine changing at arbitrary points in time.
For example, if SP state is currently in SP29:SAS_Train state and
transmitting the TRAIN pattern, when the conditions to transition to
SP30:SAS_TrainingDone occur at an arbitrary point in time, the SP
transmitter would then switch to sending TRAIN_DONE patterns.  
In other words, there may be less than 58 dwords of random scrambled data
between the TRAIN and TRAIN_DONE primitive sequences.
Actually, there might not be anything preventing the TRAIN primitive itself
|from being less than 6 dwords when making this transition... I'm not sure on
this one to be honest.
Same reasoning applies when going from the TrainingDone to PHY_Ready state.
Is there objection to this type of allowed behavior?  Would that behavior be
okay for the receiver that is still training without messing up the training
algorithm?
I feel this should be allowed behavior from a digital state machine design
standpoint, as it keeps it simple... the actual implementation of the SP
state machine does need to know about the specific dword "state"
of the training pattern.  
Brian Day
LSI Logic
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Stephen
FINCH
Sent: Friday, November 17, 2006 8:54 AM
To: T10 Reflector
Subject: SAS2: Speed Negotiation proposal 06-515r0 (formerly 06-423r9) now
available
* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
Following the review during the SAS2 Phy conference call yesterday,
editorial updates have been made to 06-324.  We ran out of revision numbers,
so a new document number has been generated.
NO TECHNICAL CHANGES WERE MADE.
It is my belief that we now have the SAS2 speed negotiation process well
defined.  I plan to move to include this information into the SAS2 draft at
the January meetings, so take the time now to review this material.
Regards,
Steve Finch
STMicroelectronics
303 381-3587
Steve.finch at st.com
*
* 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 arobinso at vitesse.com  Tue Nov 21 15:58:43 2006
From: arobinso at vitesse.com (Adrian Robinson)
Date: Tue, 21 Nov 2006 16:58:43 -0700
Subject: SAS2 Speed Negotiation 06-515 switching between patterns
Message-ID: <mailman.962.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Adrian Robinson <arobinso at vitesse.com>
*
I would have to support Steve's interpretation.  That way,
anyone who's training algorithm wants to take advantage of
a known pattern, won't get messed up by the switch.  It's
probably not a problem, but who knows.
Adrian Robinson
Vitesse Semiconductor
On Tue, 2006-11-21 at 13:32, Stephen FINCH wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Stephen FINCH <steve.finch at st.com>
> *
> 
> Brian,
> 
> You've made a good point.  It isn't clear.  But I do have an interpretation
> that may apply.
> 
> My interpretation is that the SP state machine sends a Transmit TRAIN_DONE
> pattern message to the SP transmitter, the SP transmitter does the
> transmission and generates a TRAIN_DONE Pattern Transmitted when it has
> completed the transmission.  It doesn't honor any other transmission
> requests until the one it is working on is completed.
> 
> The same sequence is true of the Transmit TRAIN pattern, except that the
> TRAIN Pattern Transmitted is not received/used within the SP state machine.
> Logically, the TRAIN Pattern Transmitted occurs even if it doesn't cause a
> message to be sent.
> 
> This is implied in other state machines.  A case in point is state
> SL_CC4:DisconnectWait state.	Upon entry, it sends a Transmit CLOSE
(Normal)
> message or Transmit CLOSE (Clear Affiliation) message to the SL
transmitter.
> Transition SL_CC4:DisconnectWait to SL_CC0:Idle is described as:
> 
> "This transition shall occur after:
> a) sending a Transmit CLOSE message to the SL transmitter;
> b) receiving a CLOSE Received message; and
> c) sending a Connection Closed (Normal) confirmation to the port layer."
> 
> Note that it doesn't wait for a CLOSE Transmitted message from the SL
> transmitter.	The CLOSE is a triple, so the receiving of a CLOSE Received
> message could occur before the transmitter has completed send the requested
> CLOSE.  We know that the outgoing CLOSE must be sent in its entirety or
else
> we would be getting CLOSE timeouts frequently. 
> 
> I have always interpreted these sequences in the state machines such that,
> once a transmitter starts working on a Transmit xxxx message, it completes
> that transmission BEFORE it starts on any new transmission.
> 
> If this interpretation is right, then the transmitter, in response to a
> request to Transmit TRAIN pattern or Transmit TRAIN_DONE pattern, would
> always send a complete pattern before honoring a new Transmit xxxxx
message.
> So, the transition from SP29:SAS_Train state to SP30:SAS_TrainingDone state
> can occur in the middle of the transmission of a TRAIN pattern, but the
> transmitter would complete the transmission of the TRAIN pattern that it
> started in response to the Transmit TRAIN pattern request of SP29, and then
> look at the Transmit TRAIN_DONE pattern from SP30 and do that next.
> 
> Again, this is my interpretation.  
> 
> Are there any other comments???  Agreements??? Disagreements???
> 
> 
> Steve Finch
> STMicroelectronics
> 303 381-3587
> 
> -----Original Message-----
> From: Day, Brian [mailto:Brian.Day at lsi.com] 
> Sent: Tuesday, November 21, 2006 12:22 PM
> To: Stephen FINCH; T10 Reflector
> Subject: SAS2 Speed Negotiation 06-515 switching between patterns
> 
> 
> So as I interpret this (which is the point of my question), it would be
okay
> to truncate the both the TRAIN pattern and TRAIN_DONE when switching to a
> new pattern due to the state machine changing at arbitrary points in time.
> 
> For example, if SP state is currently in SP29:SAS_Train state and
> transmitting the TRAIN pattern, when the conditions to transition to
> SP30:SAS_TrainingDone occur at an arbitrary point in time, the SP
> transmitter would then switch to sending TRAIN_DONE patterns.  
> In other words, there may be less than 58 dwords of random scrambled data
> between the TRAIN and TRAIN_DONE primitive sequences.
> Actually, there might not be anything preventing the TRAIN primitive itself
> from being less than 6 dwords when making this transition... I'm not sure
on
> this one to be honest.
> 
> Same reasoning applies when going from the TrainingDone to PHY_Ready state.
> 
> Is there objection to this type of allowed behavior?	Would that behavior
be
> okay for the receiver that is still training without messing up the
training
> algorithm?
> 
> I feel this should be allowed behavior from a digital state machine design
> standpoint, as it keeps it simple... the actual implementation of the SP
> state machine does need to know about the specific dword "state"
> of the training pattern.  
> 
> Brian Day
> LSI Logic
> 
> 
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Stephen
> FINCH
> Sent: Friday, November 17, 2006 8:54 AM
> To: T10 Reflector
> Subject: SAS2: Speed Negotiation proposal 06-515r0 (formerly 06-423r9) now
> available
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Stephen FINCH <steve.finch at st.com>
> *
> 
> Following the review during the SAS2 Phy conference call yesterday,
> editorial updates have been made to 06-324.  We ran out of revision
numbers,
> so a new document number has been generated.
> 
> NO TECHNICAL CHANGES WERE MADE.
> 
> It is my belief that we now have the SAS2 speed negotiation process well
> defined.  I plan to move to include this information into the SAS2 draft at
> the January meetings, so take the time now to review this material.
> 
> Regards,
> 
> Steve Finch
> STMicroelectronics
> 303 381-3587
> Steve.finch at st.com
> 
> 
> 
> *
> * 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
-- 
Adrian Robinson <arobinso at vitesse.com>
Vitesse Semiconductor Corporation
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Tim_Symons at pmc-sierra.com  Tue Nov 21 17:21:59 2006
From: Tim_Symons at pmc-sierra.com (Tim Symons)
Date: Tue, 21 Nov 2006 17:21:59 -0800
Subject: SAS2 Speed Negotiation 06-515 switching between patterns
Message-ID: <mailman.963.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Tim Symons <Tim_Symons at pmc-sierra.com>
*
I agree with Steve's interpretation also. The pattern should be considered a
"contiguous set" that does not get abbreviated by any other transitions.
Regards
	Tim.
Tim Symons
Principal Engineer
PMC-Sierra Ltd.
Burnaby
Cell: 778 998 5025
E-mail Tim_Symons at pmc-sierra.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Adrian
Robinson
Sent: Tuesday, November 21, 2006 3:59 PM
To: Stephen FINCH
Cc: 'Day, Brian'; 'T10 Reflector'
Subject: RE: SAS2 Speed Negotiation 06-515 switching between patterns
* From the T10 Reflector (t10 at t10.org), posted by:
* Adrian Robinson <arobinso at vitesse.com>
*
I would have to support Steve's interpretation.  That way, anyone who's
training algorithm wants to take advantage of a known pattern, won't get
messed up by the switch.  It's probably not a problem, but who knows.
Adrian Robinson
Vitesse Semiconductor
On Tue, 2006-11-21 at 13:32, Stephen FINCH wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Stephen FINCH <steve.finch at st.com>
> *
> 
> Brian,
> 
> You've made a good point.  It isn't clear.  But I do have an 
> interpretation that may apply.
> 
> My interpretation is that the SP state machine sends a Transmit 
> TRAIN_DONE pattern message to the SP transmitter, the SP transmitter 
> does the transmission and generates a TRAIN_DONE Pattern Transmitted 
> when it has completed the transmission.  It doesn't honor any other 
> transmission requests until the one it is working on is completed.
> 
> The same sequence is true of the Transmit TRAIN pattern, except that 
> the TRAIN Pattern Transmitted is not received/used within the SP state
machine.
> Logically, the TRAIN Pattern Transmitted occurs even if it doesn't 
> cause a message to be sent.
> 
> This is implied in other state machines.  A case in point is state 
> SL_CC4:DisconnectWait state.	Upon entry, it sends a Transmit CLOSE 
> (Normal) message or Transmit CLOSE (Clear Affiliation) message to the SL
transmitter.
> Transition SL_CC4:DisconnectWait to SL_CC0:Idle is described as:
> 
> "This transition shall occur after:
> a) sending a Transmit CLOSE message to the SL transmitter;
> b) receiving a CLOSE Received message; and
> c) sending a Connection Closed (Normal) confirmation to the port layer."
> 
> Note that it doesn't wait for a CLOSE Transmitted message from the SL 
> transmitter.	The CLOSE is a triple, so the receiving of a CLOSE 
> Received message could occur before the transmitter has completed send 
> the requested CLOSE.	We know that the outgoing CLOSE must be sent in 
> its entirety or else we would be getting CLOSE timeouts frequently.
> 
> I have always interpreted these sequences in the state machines such 
> that, once a transmitter starts working on a Transmit xxxx message, it 
> completes that transmission BEFORE it starts on any new transmission.
> 
> If this interpretation is right, then the transmitter, in response to 
> a request to Transmit TRAIN pattern or Transmit TRAIN_DONE pattern, 
> would always send a complete pattern before honoring a new Transmit xxxxx
message.
> So, the transition from SP29:SAS_Train state to SP30:SAS_TrainingDone 
> state can occur in the middle of the transmission of a TRAIN pattern, 
> but the transmitter would complete the transmission of the TRAIN 
> pattern that it started in response to the Transmit TRAIN pattern 
> request of SP29, and then look at the Transmit TRAIN_DONE pattern from SP30
and do that next.
> 
> Again, this is my interpretation.  
> 
> Are there any other comments???  Agreements??? Disagreements???
> 
> 
> Steve Finch
> STMicroelectronics
> 303 381-3587
> 
> -----Original Message-----
> From: Day, Brian [mailto:Brian.Day at lsi.com]
> Sent: Tuesday, November 21, 2006 12:22 PM
> To: Stephen FINCH; T10 Reflector
> Subject: SAS2 Speed Negotiation 06-515 switching between patterns
> 
> 
> So as I interpret this (which is the point of my question), it would 
> be okay to truncate the both the TRAIN pattern and TRAIN_DONE when 
> switching to a new pattern due to the state machine changing at arbitrary
points in time.
> 
> For example, if SP state is currently in SP29:SAS_Train state and 
> transmitting the TRAIN pattern, when the conditions to transition to 
> SP30:SAS_TrainingDone occur at an arbitrary point in time, the SP 
> transmitter would then switch to sending TRAIN_DONE patterns.
> In other words, there may be less than 58 dwords of random scrambled 
> data between the TRAIN and TRAIN_DONE primitive sequences.
> Actually, there might not be anything preventing the TRAIN primitive 
> itself from being less than 6 dwords when making this transition... 
> I'm not sure on this one to be honest.
> 
> Same reasoning applies when going from the TrainingDone to PHY_Ready state.
> 
> Is there objection to this type of allowed behavior?	Would that 
> behavior be okay for the receiver that is still training without 
> messing up the training algorithm?
> 
> I feel this should be allowed behavior from a digital state machine 
> design standpoint, as it keeps it simple... the actual implementation 
> of the SP state machine does need to know about the specific dword "state"
> of the training pattern.  
> 
> Brian Day
> LSI Logic
> 
> 
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of 
> Stephen FINCH
> Sent: Friday, November 17, 2006 8:54 AM
> To: T10 Reflector
> Subject: SAS2: Speed Negotiation proposal 06-515r0 (formerly 06-423r9) 
> now available
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Stephen FINCH <steve.finch at st.com>
> *
> 
> Following the review during the SAS2 Phy conference call yesterday, 
> editorial updates have been made to 06-324.  We ran out of revision 
> numbers, so a new document number has been generated.
> 
> NO TECHNICAL CHANGES WERE MADE.
> 
> It is my belief that we now have the SAS2 speed negotiation process 
> well defined.  I plan to move to include this information into the 
> SAS2 draft at the January meetings, so take the time now to review this
material.
> 
> Regards,
> 
> Steve Finch
> STMicroelectronics
> 303 381-3587
> Steve.finch at st.com
> 
> 
> 
> *
> * 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
--
Adrian Robinson <arobinso at vitesse.com>
Vitesse Semiconductor Corporation
*
* 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 Peter at Smart-Projects.net  Wed Nov 22 17:51:47 2006
From: Peter at Smart-Projects.net (Peter Van Hove)
Date: Thu, 23 Nov 2006 02:51:47 +0100
Subject: IsoBuster BD and HD DVD support
Message-ID: <mailman.964.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Peter Van Hove" <Peter at Smart-Projects.net>
*
I recently implemented BD and HD DVD support in IsoBuster.
If you have access to BD and/or HD DVD discs and drives, and you want to
check out the "limited distribution" beta version of IsoBuster, please drop
me a private email and I'll gladly send it to you.  It may help you in your
development ?  And I can benefit from the feedback.
This version will go public mid December.
This is a long shot but ... I'm in need of BD and HD DVD drives and discs to
be able to implement and test properly.
I suppose this message is for the manufacturers:
If you have drive(s) and disc(s) you can live without and you don't mind
sending them to me, I'll gladly be on the receiving end :)
This will allow me to test properly and obviously you will be assured that 
your hardware works well with IsoBuster.
Best Regards,
Peter
-------------------------------------------------------
Peter Van Hove
CD and DVD Data recovery
Peter at Smart-Projects.net
www.Smart-Projects.net
www.IsoBuster.com
------------------------------------------------------- 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gary.Franco at emulex.com  Sat Nov 25 05:17:16 2006
From: Gary.Franco at emulex.com (Gary.Franco at emulex.com)
Date: Sat, 25 Nov 2006 05:17:16 -0800
Subject: Type 3 protection 
Message-ID: <mailman.965.1441607311.22510.t10@sandbox.t10.org>

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

I would like a clarification on the correct implementation for Type 3
checking when dealing with WRPROTECT/RDPROTECT/VRPROTECT .
In SBC-3r07 clause 4.17.2.5 Type 3 protection states:
Type 3 protection:
a)	defines the content of the LOGICAL BLOCK GUARD field within the
logical blocks of the data-in buffer and/or data-out buffer;
b)	does not define the content of the LOGICAL BLOCK APPLICATION TAG
field; and
c)	does not define the content of the LOGICAL BLOCK REFERENCE TAG
field.
However in the individual command descriptors, WRITE(10) for example,
Table 71 - WRPROTECT field indicates that both the Application Tag and
Reference Tag should be checked.
Since both of these DIF items are not defined for Type 3 protection, I
assume that for Type 3 protected devices these fields should not be
checked at all.
Can someone clarify?
Thanks in advance
__________________________________
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 
Be who you are and say what you feel because those who mind don't matter
and those who matter don't mind.
-Dr. Seuss
This message contains confidential information of Emulex Corporation
intended only for listed recipients and should not be forwarded to
anyone else.  
If you have received this message in error, please delete it
immediately.  Thank you. 


From lohmeyer at t10.org  Sat Nov 25 23:03:27 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 26 Nov 2006 00:03:27 -0700
Subject: Recent T10 documents uploaded since 2006/11/19
Message-ID: <mailman.966.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
Working Drafts
--------------
(Report generated on 2006/11/26 at 00:03:25)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From gop at us.ibm.com  Mon Nov 27 06:49:06 2006
From: gop at us.ibm.com (George Penokie)
Date: Mon, 27 Nov 2006 08:49:06 -0600
Subject: Type 3 protection
Message-ID: <mailman.967.1441607311.22510.t10@sandbox.t10.org>

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

Gary,
The rules for checking are in the footnotes. For example in table 71 
footnote j describes the rules for checking the Reference Tag:
If type 1 protection is enabled, the device server checks the logical 
block reference tag by comparing it to the lower 4 bytes of the LBA 
associated with the logical block. If type 2 protection or type 3 
protection is enabled, the device server checks the logical block 
reference tag if it has knowledge of the contents of the LOGICAL BLOCK 
REFERENCE TAG field. If type 2 protection is enabled, then this knowledge 
may be acquired through the EXPECTED INITIAL LOGICAL BLOCK REFERENCE TAG 
field in a WRITE (32) command (see 5.29). If type 3 protection is enabled, 
then the method for acquiring this knowledge is not defined by this 
standard.
That footnote is telling you that for type 3 protection the target only 
check the reference tag if the target knows what the content is be some 
means not defined by the standard. 
Also, sending out a message on this reflector that states the information 
is "confidential information of Emulex Corporation" is a not a good way to 
get responses. In the future any such messages received on my machine will 
automatically be deleted.
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
Gary.Franco at Emulex.Com 
Sent by: owner-t10 at t10.org
11/25/2006 07:17 AM
To
<t10 at t10.org>
cc
Subject
Type 3 protection
I would like a clarification on the correct implementation for Type 3 
checking when dealing with WRPROTECT/RDPROTECT/VRPROTECT .
In SBC-3r07 clause 4.17.2.5 Type 3 protection states:
Type 3 protection:
a)	defines the content of the LOGICAL BLOCK GUARD field within the 
logical blocks of the data-in buffer and/or data-out buffer;
b)	does not define the content of the LOGICAL BLOCK APPLICATION TAG 
field; and
c)	does not define the content of the LOGICAL BLOCK REFERENCE TAG 
field.
However in the individual command descriptors, WRITE(10) for example, 
Table 71 ? WRPROTECT field indicates that both the Application Tag and 
Reference Tag should be checked.
Since both of these DIF items are not defined for Type 3 protection, I 
assume that for Type 3 protected devices these fields should not be 
checked at all.
Can someone clarify?
Thanks in advance
__________________________________
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 
Be who you are and say what you feel because those who mind don't matter 
and those who matter don't mind.
-Dr. Seuss
Thank you. 


From David.Peterson at mcdata.com  Mon Nov 27 08:00:37 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Mon, 27 Nov 2006 09:00:37 -0700
Subject: SSC-3: Dec 11th Conf Call 
Message-ID: <mailman.968.1441607311.22510.t10@sandbox.t10.org>

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

Howdy All,
There will be an SSC-3 conference call on Monday Dec 11th at
11:00am-1:00pm central time
Below is the call in information:
URL: http://mcdata.raindance.com <http://mcdata.raindance.com/&gt; 
Conference ID: 5478097
Dial-in number: 1-800-653-7492
International Dial-in number: 1-770-325-4745
The main agenda for the conference call will be Security.
Thanks...Dave 
(no disclaimer)


From michael.banther at hp.com  Mon Nov 27 08:04:45 2006
From: michael.banther at hp.com (Banther, Michael)
Date: Mon, 27 Nov 2006 16:04:45 -0000
Subject: SMC-3 teleconference
Message-ID: <mailman.969.1441607311.22510.t10@sandbox.t10.org>

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

Hello all,
Today's telecon has completely slipped my mind.  Thanks to Paul Entzel
to alterting to to it!	My sincere apologies to all.  However given the
lack of preparation of both myself and the secretary, I cannot see any
way to meet today.  I will endevor to reschedule.
Regards,
Michael Banther
Hewlett-Packard Ltd.
+44 117 312 9503


From James.C.Hatfield at seagate.com  Mon Nov 27 10:10:11 2006
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Mon, 27 Nov 2006 11:10:11 -0700
Subject: [t13] Meeting announcement: TCG Working Group: ATA/SCSI Interactions 
Message-ID: <mailman.970.1441607311.22510.t10@sandbox.t10.org>

This message is from the T13 list server.
TCG (Storage Working Group) is starting to hold meetings to discuss
interactions between TCG features and
interface (e.g. ATA and SCSI) commands and features. The first two are:
      December	  1, 2006
      December 15, 2006
If you already are a member of the TCG Storage Working Group (SWG),
please see the TCG Storage Working Group calendar for details.
If your company is already a TCG member, you can register to get access to
the Storage Working Group:
> https://www.trustedcomputinggroup.org/kmembership_info/person_signup
To join TCG:
> https://www.trustedcomputinggroup.org/join/
---------------
Friday, Dec 1, 2006
11:00 AM - 1:00 PM Eastern (USA) Time
Agenda:
TCG Storage Work Group ??? Interface Interactions subgroup
Agenda for Meeting ??? December 1, 2006
Scope
- Identify interactions between the Locking SP and interface specifications
      o ATA/ATAPI
      o SCSI
Schedule outline (proposed)
- Dec. 31, 2007 ??? T10 approves appropriate proposals for incorporation
- Dec. 31, 2007 ??? T13 approves appropriate proposals for incorporation
- Dec. 31, 2007 ??? SATA-IO approves appropriate proposals for incorporation
- Dec. 31, 2007 ??? TCG approves appropriate proposals for incorporation
Organizational issues
- meeting frequency, locations
- who should attend
- how to get the appropriate people to participate
Brainstorm list of ATA issues (30 minutes)
Brainstorm list of SCSI issues (30 minutes)
Next Steps
---------------
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
==========================================


From lohmeyer at t10.org  Mon Nov 27 09:50:09 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 27 Nov 2006 10:50:09 -0700
Subject: T10 Reflector clean up
Message-ID: <mailman.971.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
#
#
#
#
#
#
#
#
#
#
It is time again to clean up the T10 Reflector. The following addresses have
bounced consistently since the last clean up:
Addresses removed:
   maiyenga at cisco.com
   Joe_Neaz at vos.stratus.com
   Matt_Hambrick at adaptec.com
   Gregg_Neely at us.xyratex.com
   Jorge_Monterrosa at adaptec.com
   greg at vitesse.com
   Larrie_Carr at pmc-sierra.com
These people may re-subscribe (hopefully, with a better address) by sending
an email to majordomo at t10.org with the following line in the message body:
  subscribe t10
Regards,
--
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 roger_cummings at symantec.com  Mon Nov 27 10:11:15 2006
From: roger_cummings at symantec.com (Roger Cummings)
Date: Mon, 27 Nov 2006 13:11:15 -0500
Subject: SMC-3 teleconference on THURSDAY this week
Message-ID: <mailman.972.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Roger Cummings" <roger_cummings at symantec.com>
*
Folks,
Please see below for the agenda and contact information for a SMC-3
teleconference that will be held on THURSDAY this week at 8am PST.
Apologies for the fact that t10.org originally showed this call as
happening today - that has now been corrected.
Regards,
Roger Cummings
SMC-3 Secretary
roger_cummings at symantec.com
Draft Agenda -- SCSI Media Changer (SMC) Working Group Teleconference
	Date -- 30 November 2006
	Time -- 8.00 AM PST, 11.00 AM EST, 16.00 AM GMT
    Duration -- Two hours
    Call-ins -- Germany     -- 069 2222 20433
		Netherlands -- 020 713 2919
		Norway	    -- 800 10938
		U.K.	    -- 0800 073 8926
		U.S.	    -- 1 866 276 8920
     Conf ID -- 319549
1.  Introductions
2.  Approval of the Agenda
3.  INCITS Patent Policy (see T10 Short Summary at
http://www.t10.org/patpol.htm)
4.  Old Business
4.1   SMC-3 Add PREVENT ALLOW MEDIA REMOVAL command (06-442) [Snelder]
4.2   SMC-3 Medium type codes (06-452) [Snelder]
4.3   SMC-3 Support column in mode page codes and subpage codes table
(06-456) [Snelder]
4.4   SMC-3 Command table and INQUIRY clean-up (06-477) [Banther]
4.5   SMC-3 Discussion: Visibility of Volumes in Elements (06-421)
[Ballard]
4.6   SMC-3 TapeAlert Enhancements (06-420) [Banther]
4.7   SMC-3, Report Element Information (06-272) [Ballard]
4.8   SMC-3 Error codes overview (06-397) [Snelder]
4.9   SMC-3: Diagnostics Data log page (06-395) [Marks]
4.10  SMC-3: Element Statistics log page for SMC (06-394) [Marks]
4.11  Working List for ISV feedback (SMC/SSC/ADC/SPC) (05-315) [Butt]
5.  New Business
6.  Review New Action Items
7.  Adjournment
*
* 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  Mon Nov 27 10:10:11 2006
From: James.C.Hatfield at seagate.com (James.C.Hatfield at seagate.com)
Date: Mon, 27 Nov 2006 11:10:11 -0700
Subject: Meeting announcement: TCG Working Group: ATA/SCSI Interactions 
Message-ID: <mailman.973.1441607311.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
TCG (Storage Working Group) is starting to hold meetings to discuss
interactions between TCG features and
interface (e.g. ATA and SCSI) commands and features. The first two are:
      December	  1, 2006
      December 15, 2006
If you already are a member of the TCG Storage Working Group (SWG),
please see the TCG Storage Working Group calendar for details.
If your company is already a TCG member, you can register to get access to
the Storage Working Group:
> https://www.trustedcomputinggroup.org/kmembership_info/person_signup
To join TCG:
> https://www.trustedcomputinggroup.org/join/
---------------
Friday, Dec 1, 2006
11:00 AM - 1:00 PM Eastern (USA) Time
Agenda:
TCG Storage Work Group ??? Interface Interactions subgroup
Agenda for Meeting ??? December 1, 2006
Scope
- Identify interactions between the Locking SP and interface specifications
      o ATA/ATAPI
      o SCSI
Schedule outline (proposed)
- Dec. 31, 2007 ??? T10 approves appropriate proposals for incorporation
- Dec. 31, 2007 ??? T13 approves appropriate proposals for incorporation
- Dec. 31, 2007 ??? SATA-IO approves appropriate proposals for incorporation
- Dec. 31, 2007 ??? TCG approves appropriate proposals for incorporation
Organizational issues
- meeting frequency, locations
- who should attend
- how to get the appropriate people to participate
Brainstorm list of ATA issues (30 minutes)
Brainstorm list of SCSI issues (30 minutes)
Next Steps
---------------
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 roger_cummings at symantec.com  Mon Nov 27 13:07:13 2006
From: roger_cummings at symantec.com (Roger Cummings)
Date: Mon, 27 Nov 2006 16:07:13 -0500
Subject: REMINDER: Cut-off date for January meeting is this FRIDAY
Message-ID: <mailman.974.1441607311.22510.t10@sandbox.t10.org>

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

Folks,
This is a quick reminder that the cut-off date for the room block at the
Orlando Lake Mary Marriott for the January T10 meeting is December 1,
which is FRIDAY THIS WEEK.
Thanks to those people who have already made their reservations, and
would the others please do so ASAP. You can make the reservation
directly yourself via the web at:
http://marriott.com/property/propertypage/mcoml?groupCode=ansansa&app=re
svlink
if your travel department is not yet ready to do so.
For all other information about the meeting, see:
http://www.t10.org/ftp/t10/announce/ann-m077.pdf
Please let me know if you need and further information.
Regards,
Roger Cummings
SYMANTEC
roger_cummings at symantec.com


From ai.takaharu at jp.panasonic.com  Tue Nov 28 05:00:04 2006
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Tue, 28 Nov 2006 22:00:04 +0900
Subject: Implementation note for Enhanced defect reporting
Message-ID: <mailman.975.1441607311.22510.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0611280_dow_recommendation.zip">dow_recommendation.zip</A>

Hello Mt.Fuji people,
We would like to propose to add an implementation note to Mt.Fuji
document regarding Enhanced defect reporting.
Enclosed please find the proposal document.
Best Regards,
Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan


From ai.takaharu at jp.panasonic.com  Tue Nov 28 04:56:41 2006
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Tue, 28 Nov 2006 21:56:41 +0900
Subject: Proposed amendment to DVD-RW DL commands
Message-ID: <mailman.976.1441607311.22510.t10@sandbox.t10.org>

Attachment #1: <A HREF="r0611281_detail_of_the_proposal_mei.zip">detail_of_the_proposal_mei.zip</A>

Hello Mt.Fuji people,
Here is the detail of the proposed amendments to Pioneer's DVD-RW DL
related proposals.
Best Regards,
Harry Ai
VEBU
Panasonic AVC Networks Company
Matsushita/Panasonic
Osaka, Japan


From Alvin.Cox at seagate.com  Tue Nov 28 06:52:52 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Tue, 28 Nov 2006 08:52:52 -0600
Subject: Reminder: SAS PHY WG call, 11/30, 10 am CST
Message-ID: <mailman.977.1441607311.22510.t10@sandbox.t10.org>

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

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 
No call on 12/28. 
Agenda (more than we can cover): 
1. SAS-2 Electrical Specification Proposal 06-496 [Witt] 
http://www.t10.org/ftp/t10/document.06/06-496r2.pdf 
a. Concentrate on page 6: Transmitter device signal characteristics.
Avoid the de-emphasis line for this call and work on the more commonly 
agreed-upon numbers. 
b. De-emphasis measurement (page 8)
It seems that the major issue with the measurement technique is the window 
location that the measurements are made.
What if Vpk is the pk-pk voltage (wherever it is at) and Vde is a mode 
value? Since the test is made on the transmitter through a zero length 
load, the mode portion should not see too large of a spread.
c. Receiver Device Signal Characteristics (page 11)
2. 10-meter cable specification issues 
http://www.t10.org/ftp/t10/document.06/06-499r0.pdf 
Any updates? 
3. EMI considerations for SAS-2 
http://www.t10.org/ftp/t10/document.06/06-483r0.pdf 
Keep in mind when developing spec. 
4. Define a loss for the zero-length test load? 
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From Mike.Jenkins at lsi.com  Wed Nov 29 18:38:54 2006
From: Mike.Jenkins at lsi.com (Jenkins, Mike)
Date: Wed, 29 Nov 2006 19:38:54 -0700
Subject: Reminder: SAS PHY WG call, 11/30, 10 am CST
Message-ID: <mailman.978.1441607311.22510.t10@sandbox.t10.org>

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

Alvin,
My apologies for being last minute, but I have uploaded Proposal for 6G
SAS Phy Specification (07-001r0)
<http://www.t10.org/ftp/t10/document.07/07-001r0.pdf&gt;  as I promised
during the last call.  If there's no time on the agenda, I understand,
but I have tried to orient this presentation for comparison with
Kevin's, so I want at least to let folks know it's there.
Regards,
Mike
Please note:  Effective October 14th, my email address will change to
Mike.Jenkins at LSI.com   .  
Effective 15 Jan 07, no other email address will be accepted by our
corporate mail server.	
Please update your address book and distribution lists accordingly.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Alvin.Cox at seagate.com
Sent: Tuesday, November 28, 2006 6:53 AM
To: t10 at t10.org
Subject: Reminder: SAS PHY WG call, 11/30, 10 am CST
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 
No call on 12/28. 
Agenda (more than we can cover): 
1. SAS-2 Electrical Specification Proposal 06-496 [Witt] 
http://www.t10.org/ftp/t10/document.06/06-496r2.pdf 
a. Concentrate on page 6: Transmitter device signal characteristics. 
Avoid the de-emphasis line for this call and work on the more commonly
agreed-upon numbers. 
b. De-emphasis measurement (page 8) 
It seems that the major issue with the measurement technique is the
window location that the measurements are made. 
What if Vpk is the pk-pk voltage (wherever it is at) and Vde is a mode
value? Since the test is made on the transmitter through a zero length
load, the mode portion should not see too large of a spread. 
c. Receiver Device Signal Characteristics (page 11) 
2. 10-meter cable specification issues 
http://www.t10.org/ftp/t10/document.06/06-499r0.pdf 
Any updates? 
3. EMI considerations for SAS-2 
http://www.t10.org/ftp/t10/document.06/06-483r0.pdf 
Keep in mind when developing spec. 
4. Define a loss for the zero-length test load? 
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809
E-Mail	alvin.cox at seagate.com