From robert.l.sheffield at intel.com  Mon May  1 08:03:20 2006
From: robert.l.sheffield at intel.com (Sheffield, Robert L)
Date: Mon, 1 May 2006 08:03:20 -0700
Subject: SAT LB Comment Resolution Teleconference (TODAY)
Message-ID: <mailman.419.1441607308.22510.t10@sandbox.t10.org>

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

There is a SAT LB Comment Resolution Teleconference today.
Time: 12:00 noon PDT, 1:00 PM MDT, 2:00 PM CDT, 3:00 PM EDT
Duration: 3 Hours
Webex informaiton: https://intel.webex.com/intel
Webex Password: Scsi2Ata!
Webex meeting #: 821 852 981
Phone bridge: 916-356-2663, Bridge: 1, Passcode: 9682798


From David.Peterson at mcdata.com  Mon May  1 12:23:02 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Mon, 1 May 2006 14:23:02 -0500
Subject: [T11.3] FCP-4: Items for discussion
Message-ID: <mailman.420.1441607308.22510.t10@sandbox.t10.org>

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

Howdy,
Below is an email thread from Claudio that was discussed a bit at the
last FCP-4 working group meeting:
I please ask you to discuss in the FCP-4 WG the possibility to mandate
continuous increasing SEQ_CNT in FCP-4. Relying on it greatly simplifies
the detection of a missing Sequence and consequently simplifies error
recovery, but today is optional in FCP-x (while is mandated by IP over
FC and is going to be mandated by FC-SATA).
Additional items for FCP-4 discussion follows (all due to doubts
submitted to me...):
- Bidirectional Commands: I think we need to count bytes for both
data-in and data-out. Which of these two counters should be put in the
FC4VALUE field of the REC ELS?
- Data Overlay: the FCP-3 definition of data overlay says "see SAM-3",
but SAM-3 says nothing on data overlay.
- Data Overlay: In which way could it be possible detecting a missing
Sequence when data overlay is used and continuously increasing SEQ_CNT
is not used? (it seems to us that there is no way, but others may have a
different opinion...).
- Data Overlay: how can the FC4VALUE counters can be accurate when data
overlap (i.e., how to avoid to count twice the overlapping data)?
The members of the working group came to no real concensus/resolution
per the questions and would like to open up the discussion to the
T10/T11 commitees, specifically making Continuously Increasing SEQ_CNT a
requirement for FCP-4.
Regarding Continuously Increasing SEQ_CNT:
We have discussed requiring Continuously Increasing SEQ_CNT during each
previous FCP-x standard development efforts and folk opted to not
specify it as a requirement since some vendors did not yet fully support
it. We may have now moved past that issue. 
Regarding Bidirectional Commands:
FCP-3 states: "Sequence level error recovery as described in 12.4 shall
not be used for bidirectional SCSI commands." So the question regarding
the FC4VALUE field is moot until if/when we want to support FCP-x error
detection and recovery for bidirectional commands.
Regarding Data Overlay:
The reference to SAM-3 is not intended to refer the reader to SAM-3 for
data overlay, but since it is outside the sentence this is what it
means. The reference will be removed since it provides value in this
context (i.e., the intent was to refer the reader to SAM-3 for
application client buffer offset but that is already covered).
The other two questions are vendor implementation specifc in my mind,
others may share if they wish...
Thanks...Dave
(no disclaimer)


From David.Peterson at mcdata.com  Mon May  1 12:23:02 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Mon, 1 May 2006 14:23:02 -0500
Subject: FCP-4: Items for discussion
Message-ID: <mailman.421.1441607308.22510.t10@sandbox.t10.org>

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

Howdy,
Below is an email thread from Claudio that was discussed a bit at the
last FCP-4 working group meeting:
I please ask you to discuss in the FCP-4 WG the possibility to mandate
continuous increasing SEQ_CNT in FCP-4. Relying on it greatly simplifies
the detection of a missing Sequence and consequently simplifies error
recovery, but today is optional in FCP-x (while is mandated by IP over
FC and is going to be mandated by FC-SATA).
Additional items for FCP-4 discussion follows (all due to doubts
submitted to me...):
- Bidirectional Commands: I think we need to count bytes for both
data-in and data-out. Which of these two counters should be put in the
FC4VALUE field of the REC ELS?
- Data Overlay: the FCP-3 definition of data overlay says "see SAM-3",
but SAM-3 says nothing on data overlay.
- Data Overlay: In which way could it be possible detecting a missing
Sequence when data overlay is used and continuously increasing SEQ_CNT
is not used? (it seems to us that there is no way, but others may have a
different opinion...).
- Data Overlay: how can the FC4VALUE counters can be accurate when data
overlap (i.e., how to avoid to count twice the overlapping data)?
The members of the working group came to no real concensus/resolution
per the questions and would like to open up the discussion to the
T10/T11 commitees, specifically making Continuously Increasing SEQ_CNT a
requirement for FCP-4.
Regarding Continuously Increasing SEQ_CNT:
We have discussed requiring Continuously Increasing SEQ_CNT during each
previous FCP-x standard development efforts and folk opted to not
specify it as a requirement since some vendors did not yet fully support
it. We may have now moved past that issue. 
Regarding Bidirectional Commands:
FCP-3 states: "Sequence level error recovery as described in 12.4 shall
not be used for bidirectional SCSI commands." So the question regarding
the FC4VALUE field is moot until if/when we want to support FCP-x error
detection and recovery for bidirectional commands.
Regarding Data Overlay:
The reference to SAM-3 is not intended to refer the reader to SAM-3 for
data overlay, but since it is outside the sentence this is what it
means. The reference will be removed since it provides value in this
context (i.e., the intent was to refer the reader to SAM-3 for
application client buffer offset but that is already covered).
The other two questions are vendor implementation specifc in my mind,
others may share if they wish...
Thanks...Dave
(no disclaimer)


From Gary.Franco at Emulex.Com  Mon May  1 12:56:21 2006
From: Gary.Franco at Emulex.Com (Gary.Franco at Emulex.Com)
Date: Mon, 1 May 2006 12:56:21 -0700
Subject: [T11.3] Re: FCP-4: Items for discussion
Message-ID: <mailman.422.1441607308.22510.t10@sandbox.t10.org>

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

  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David
Peterson
Sent: Monday, May 01, 2006 2:23 PM
To: t10 at t10.org; t11_3 at t11.org
Subject: FCP-4: Items for discussion
Howdy,
Below is an email thread from Claudio that was discussed a bit at the
last FCP-4 working group meeting:
I please ask you to discuss in the FCP-4 WG the possibility to mandate
continuous increasing SEQ_CNT in FCP-4. Relying on it greatly simplifies
the detection of a missing Sequence and consequently simplifies error
recovery, but today is optional in FCP-x (while is mandated by IP over
FC and is going to be mandated by FC-SATA).
Additional items for FCP-4 discussion follows (all due to doubts
submitted to me...):
- Bidirectional Commands: I think we need to count bytes for both
data-in and data-out. Which of these two counters should be put in the
FC4VALUE field of the REC ELS?
Wouldn't that be dependant on the type of command? FCP read or write
types. The device knows the current command type.
- Data Overlay: the FCP-3 definition of data overlay says "see SAM-3",
but SAM-3 says nothing on data overlay.
I would say that EMDP should be disabled cause with the end to end data
protection I do not think you can even enable this option because the
DIFs would get corrupted would they not?
- Data Overlay: In which way could it be possible detecting a missing
Sequence when data overlay is used and continuously increasing SEQ_CNT
is not used? (it seems to us that there is no way, but others may have a
different opinion...).
I agree, I think there is no possible way, at least real-time as the
data is being streamed in. At FCP response time the overrun/underrun and
residual length would cause a re-execution of the command.
- Data Overlay: how can the FC4VALUE counters can be accurate when data
overlap (i.e., how to avoid to count twice the overlapping data)?
I would think that the ability to resend data blocks already sent was
discussed in the specification as a bad thing. If not then I believe the
only way to catch a misbehaving target would be to track the data blocks
already received and keep track of the holes left behind. The device
would also have to track the resent data and not include the resent data
as data received to satisfy a read command. 
The members of the working group came to no real concensus/resolution
per the questions and would like to open up the discussion to the
T10/T11 commitees, specifically making Continuously Increasing SEQ_CNT a
requirement for FCP-4.
Making this a requirement would be a much need improvement, and one that
has been needed for a while.
Regarding Continuously Increasing SEQ_CNT:
We have discussed requiring Continuously Increasing SEQ_CNT during each
previous FCP-x standard development efforts and folk opted to not
specify it as a requirement since some vendors did not yet fully support
it. We may have now moved past that issue. 
Regarding Bidirectional Commands:
FCP-3 states: "Sequence level error recovery as described in 12.4 shall
not be used for bidirectional SCSI commands." So the question regarding
the FC4VALUE field is moot until if/when we want to support FCP-x error
detection and recovery for bidirectional commands.
Regarding Data Overlay:
The reference to SAM-3 is not intended to refer the reader to SAM-3 for
data overlay, but since it is outside the sentence this is what it
means. The reference will be removed since it provides value in this
context (i.e., the intent was to refer the reader to SAM-3 for
application client buffer offset but that is already covered).
The other two questions are vendor implementation specifc in my mind,
others may share if they wish...
Thanks...Dave
(no disclaimer)


From Gary.Franco at emulex.com  Mon May  1 12:56:21 2006
From: Gary.Franco at emulex.com (Gary.Franco at emulex.com)
Date: Mon, 1 May 2006 12:56:21 -0700
Subject: FCP-4: Items for discussion
Message-ID: <mailman.423.1441607308.22510.t10@sandbox.t10.org>

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

  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David
Peterson
Sent: Monday, May 01, 2006 2:23 PM
To: t10 at t10.org; t11_3 at t11.org
Subject: FCP-4: Items for discussion
Howdy,
Below is an email thread from Claudio that was discussed a bit at the
last FCP-4 working group meeting:
I please ask you to discuss in the FCP-4 WG the possibility to mandate
continuous increasing SEQ_CNT in FCP-4. Relying on it greatly simplifies
the detection of a missing Sequence and consequently simplifies error
recovery, but today is optional in FCP-x (while is mandated by IP over
FC and is going to be mandated by FC-SATA).
Additional items for FCP-4 discussion follows (all due to doubts
submitted to me...):
- Bidirectional Commands: I think we need to count bytes for both
data-in and data-out. Which of these two counters should be put in the
FC4VALUE field of the REC ELS?
Wouldn't that be dependant on the type of command? FCP read or write
types. The device knows the current command type.
- Data Overlay: the FCP-3 definition of data overlay says "see SAM-3",
but SAM-3 says nothing on data overlay.
I would say that EMDP should be disabled cause with the end to end data
protection I do not think you can even enable this option because the
DIFs would get corrupted would they not?
- Data Overlay: In which way could it be possible detecting a missing
Sequence when data overlay is used and continuously increasing SEQ_CNT
is not used? (it seems to us that there is no way, but others may have a
different opinion...).
I agree, I think there is no possible way, at least real-time as the
data is being streamed in. At FCP response time the overrun/underrun and
residual length would cause a re-execution of the command.
- Data Overlay: how can the FC4VALUE counters can be accurate when data
overlap (i.e., how to avoid to count twice the overlapping data)?
I would think that the ability to resend data blocks already sent was
discussed in the specification as a bad thing. If not then I believe the
only way to catch a misbehaving target would be to track the data blocks
already received and keep track of the holes left behind. The device
would also have to track the resent data and not include the resent data
as data received to satisfy a read command. 
The members of the working group came to no real concensus/resolution
per the questions and would like to open up the discussion to the
T10/T11 commitees, specifically making Continuously Increasing SEQ_CNT a
requirement for FCP-4.
Making this a requirement would be a much need improvement, and one that
has been needed for a while.
Regarding Continuously Increasing SEQ_CNT:
We have discussed requiring Continuously Increasing SEQ_CNT during each
previous FCP-x standard development efforts and folk opted to not
specify it as a requirement since some vendors did not yet fully support
it. We may have now moved past that issue. 
Regarding Bidirectional Commands:
FCP-3 states: "Sequence level error recovery as described in 12.4 shall
not be used for bidirectional SCSI commands." So the question regarding
the FC4VALUE field is moot until if/when we want to support FCP-x error
detection and recovery for bidirectional commands.
Regarding Data Overlay:
The reference to SAM-3 is not intended to refer the reader to SAM-3 for
data overlay, but since it is outside the sentence this is what it
means. The reference will be removed since it provides value in this
context (i.e., the intent was to refer the reader to SAM-3 for
application client buffer offset but that is already covered).
The other two questions are vendor implementation specifc in my mind,
others may share if they wish...
Thanks...Dave
(no disclaimer)


From David.Peterson at mcdata.com  Mon May  1 15:53:33 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Mon, 1 May 2006 17:53:33 -0500
Subject: FCP-4: Rev 00 available
Message-ID: <mailman.424.1441607308.22510.t10@sandbox.t10.org>

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

Howdy All,
FCP-4 Rev 00 has been uploaded to the T10 web site: 
http://www.t10.org/ftp/t10/drafts/fcp4/fcp4r00.pdf
<http://www.t10.org/ftp/t10/drafts/fcp4/fcp4r00.pdf&gt; 
Thanks...Dave
(no disclaimer)


From rsnively at Brocade.COM  Mon May  1 16:37:31 2006
From: rsnively at Brocade.COM (Robert Snively)
Date: Mon, 1 May 2006 16:37:31 -0700
Subject: [T11.3] Re: FCP-4: Items for discussion
Message-ID: <mailman.425.1441607308.22510.t10@sandbox.t10.org>

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

Please let me add some explanations to this to reflect some of the early
design
intentions.  My comments in red.
I please ask you to discuss in the FCP-4 WG the possibility to mandate
continuous increasing SEQ_CNT in FCP-4. Relying on it greatly simplifies
the detection of a missing Sequence and consequently simplifies error
recovery, but today is optional in FCP-x (while is mandated by IP over
FC and is going to be mandated by FC-SATA). 
While handy enough,  continuously increasing sequence count is not a
requirement
except for streamed sequences.	See FC-PLDA for the original view of
that.  Note that
some implementations choose to zero the sequence count in each sequence
because
so many exchanges may be in process at the same time.  With the offset
available
in each frame, the sequence count continuously increasing across
sequences is not 
necessary to recover all critical information.
Additional items for FCP-4 discussion follows (all due to doubts
submitted to me...):
- Bidirectional Commands: I think we need to count bytes for both
data-in and data-out. Which of these two counters should be put in the
FC4VALUE field of the REC ELS?
Wouldn't that be dependant on the type of command? FCP read or write
types. The device knows the current command type. 
See FC-LS, clause 4.2.55.4.  The  E_STAT value indicates which end holds
initiative
and whether the exchange is complete.  On bidirectional commands, I
would expect
the FC4VALUE to reflect the phase that is active when the REC arrives.
Note that REC
is supplemented by lots of other information in determining this value,
so it is the
responder who must make up its mind and make sure that information is
consistent.
- Data Overlay: the FCP-3 definition of data overlay says "see SAM-3",
but SAM-3 says nothing on data overlay.
I would say that EMDP should be disabled cause with the end to end data
protection I do not think you can even enable this option because the
DIFs would get corrupted would they not? 
Realistically EMDP=1 behavior is rarely implemented.  However, when it
is implemented,
there is an understanding that the target and initiator know how to
handle it.  DIFs would
only be corrupted if the target or initiator did NOT know how to handle
EMDP.  If DIFs
were used with EMDP, I would expect that full buffer accumulation and
post-processing
would be required to accumulate the proper check values, making it even
less likely
that EMDP would be supported, but not creating grounds to forbid it from
the architecture. 
- Data Overlay: In which way could it be possible detecting a missing
Sequence when data overlay is used and continuously increasing SEQ_CNT
is not used? (it seems to us that there is no way, but others may have a
different opinion...).
I agree, I think there is no possible way, at least real-time as the
data is being streamed in. At FCP response time the overrun/underrun and
residual length would cause a re-execution of the command. 
Continuously increasing sequence count does not help recover from
failures in
proper transmission during data overlay transfers.  If you are using
data overlay,
the receiving device must keep a mask indicating which data has been
transferred
and which has not in order to maintain the data counts correctly.  Note
that data
overlay may even transfer the same data twice, but it must be counted
only once.  A missing
block in the middle is treated as defined in FCP-3 clause 9.4.1, below:
 " If error conditions occur that prevent the transfer of data in the
middle of a  
 data transfer, the FCP_SNS_INFO shall indicate that only data from the
offset of  
 zero up to the first byte of missing data has been transferred " 
- Data Overlay: how can the FC4VALUE counters can be accurate when data
overlap (i.e., how to avoid to count twice the overlapping data)?
I would think that the ability to resend data blocks already sent was
discussed in the specification as a bad thing. If not then I believe the
only way to catch a misbehaving target would be to track the data blocks
already received and keep track of the holes left behind. The device
would also have to track the resent data and not include the resent data
as data received to satisfy a read command.  
The resending of data blocks may be a good thing if the first copy was
sent with
incorrect data.  However, you are completely correct when you say that
the
initiator must track the data blocks received, counting each one only
once even if
it was received multiple times.  Note that there is no requirement for
the initiator to guarantee data 
integrity with such tools, but it would  be foolish to allow EMDP=1
behavior
without such checks.
The members of the working group came to no real concensus/resolution
per the questions and would like to open up the discussion to the
T10/T11 commitees, specifically making Continuously Increasing SEQ_CNT a
requirement for FCP-4.
Making this a requirement would be a much need improvement, and one that
has been needed for a while.  
I disagree.  See above and below.
Regarding Continuously Increasing SEQ_CNT:
We have discussed requiring Continuously Increasing SEQ_CNT during each
previous FCP-x standard development efforts and folk opted to not
specify it as a requirement since some vendors did not yet fully support
it. We may have now moved past that issue.  
Sorry, while that may be true of individual drives, it would be a
problem for devices with
large numbers of exchanges outstanding, each requiring context
information for transfers
in both directions.  There is no particular improvement in checking
because of this, since
data offsets are carried in every header. 
Regarding Bidirectional Commands:
FCP-3 states: "Sequence level error recovery as described in 12.4 shall
not be used for bidirectional SCSI commands." So the question regarding
the FC4VALUE field is moot until if/when we want to support FCP-x error
detection and recovery for bidirectional commands. 
I believe we can allow recovery for bidirectional SCSI commands using
the additional information
in the E_STAT field in the REC and the information in the SRR.	It would
take a bit of work,
but it should not be too demanding an exercise since bidirectional
commands are required
to complete one transfer before starting the other, simplifying the
requirements significantly.
SRR may need another bit or two added.	The only reason we didn't do it
in the earlier revisions
was that bidirectional SCSI commands were added late in one of the FCP-x
documents and
nobody has bothered to revisit the retry processes with such commands in
mind.
Regarding Data Overlay:
The reference to SAM-3 is not intended to refer the reader to SAM-3 for
data overlay, but since it is outside the sentence this is what it
means. The reference will be removed since it provides value in this
context (i.e., the intent was to refer the reader to SAM-3 for
application client buffer offset but that is already covered).
The other two questions are vendor implementation specifc in my mind,
others may share if they wish... 
 Agreed.  See above.


From rsnively at Brocade.COM  Mon May  1 16:37:31 2006
From: rsnively at Brocade.COM (Robert Snively)
Date: Mon, 1 May 2006 16:37:31 -0700
Subject: [T11.3] Re: FCP-4: Items for discussion
Message-ID: <mailman.426.1441607308.22510.t10@sandbox.t10.org>

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

Please let me add some explanations to this to reflect some of the early
design
intentions.  My comments in red.
I please ask you to discuss in the FCP-4 WG the possibility to mandate
continuous increasing SEQ_CNT in FCP-4. Relying on it greatly simplifies
the detection of a missing Sequence and consequently simplifies error
recovery, but today is optional in FCP-x (while is mandated by IP over
FC and is going to be mandated by FC-SATA). 
While handy enough,  continuously increasing sequence count is not a
requirement
except for streamed sequences.	See FC-PLDA for the original view of
that.  Note that
some implementations choose to zero the sequence count in each sequence
because
so many exchanges may be in process at the same time.  With the offset
available
in each frame, the sequence count continuously increasing across
sequences is not 
necessary to recover all critical information.
Additional items for FCP-4 discussion follows (all due to doubts
submitted to me...):
- Bidirectional Commands: I think we need to count bytes for both
data-in and data-out. Which of these two counters should be put in the
FC4VALUE field of the REC ELS?
Wouldn't that be dependant on the type of command? FCP read or write
types. The device knows the current command type. 
See FC-LS, clause 4.2.55.4.  The  E_STAT value indicates which end holds
initiative
and whether the exchange is complete.  On bidirectional commands, I
would expect
the FC4VALUE to reflect the phase that is active when the REC arrives.
Note that REC
is supplemented by lots of other information in determining this value,
so it is the
responder who must make up its mind and make sure that information is
consistent.
- Data Overlay: the FCP-3 definition of data overlay says "see SAM-3",
but SAM-3 says nothing on data overlay.
I would say that EMDP should be disabled cause with the end to end data
protection I do not think you can even enable this option because the
DIFs would get corrupted would they not? 
Realistically EMDP=1 behavior is rarely implemented.  However, when it
is implemented,
there is an understanding that the target and initiator know how to
handle it.  DIFs would
only be corrupted if the target or initiator did NOT know how to handle
EMDP.  If DIFs
were used with EMDP, I would expect that full buffer accumulation and
post-processing
would be required to accumulate the proper check values, making it even
less likely
that EMDP would be supported, but not creating grounds to forbid it from
the architecture. 
- Data Overlay: In which way could it be possible detecting a missing
Sequence when data overlay is used and continuously increasing SEQ_CNT
is not used? (it seems to us that there is no way, but others may have a
different opinion...).
I agree, I think there is no possible way, at least real-time as the
data is being streamed in. At FCP response time the overrun/underrun and
residual length would cause a re-execution of the command. 
Continuously increasing sequence count does not help recover from
failures in
proper transmission during data overlay transfers.  If you are using
data overlay,
the receiving device must keep a mask indicating which data has been
transferred
and which has not in order to maintain the data counts correctly.  Note
that data
overlay may even transfer the same data twice, but it must be counted
only once.  A missing
block in the middle is treated as defined in FCP-3 clause 9.4.1, below:
 " If error conditions occur that prevent the transfer of data in the
middle of a  
 data transfer, the FCP_SNS_INFO shall indicate that only data from the
offset of  
 zero up to the first byte of missing data has been transferred " 
- Data Overlay: how can the FC4VALUE counters can be accurate when data
overlap (i.e., how to avoid to count twice the overlapping data)?
I would think that the ability to resend data blocks already sent was
discussed in the specification as a bad thing. If not then I believe the
only way to catch a misbehaving target would be to track the data blocks
already received and keep track of the holes left behind. The device
would also have to track the resent data and not include the resent data
as data received to satisfy a read command.  
The resending of data blocks may be a good thing if the first copy was
sent with
incorrect data.  However, you are completely correct when you say that
the
initiator must track the data blocks received, counting each one only
once even if
it was received multiple times.  Note that there is no requirement for
the initiator to guarantee data 
integrity with such tools, but it would  be foolish to allow EMDP=1
behavior
without such checks.
The members of the working group came to no real concensus/resolution
per the questions and would like to open up the discussion to the
T10/T11 commitees, specifically making Continuously Increasing SEQ_CNT a
requirement for FCP-4.
Making this a requirement would be a much need improvement, and one that
has been needed for a while.  
I disagree.  See above and below.
Regarding Continuously Increasing SEQ_CNT:
We have discussed requiring Continuously Increasing SEQ_CNT during each
previous FCP-x standard development efforts and folk opted to not
specify it as a requirement since some vendors did not yet fully support
it. We may have now moved past that issue.  
Sorry, while that may be true of individual drives, it would be a
problem for devices with
large numbers of exchanges outstanding, each requiring context
information for transfers
in both directions.  There is no particular improvement in checking
because of this, since
data offsets are carried in every header. 
Regarding Bidirectional Commands:
FCP-3 states: "Sequence level error recovery as described in 12.4 shall
not be used for bidirectional SCSI commands." So the question regarding
the FC4VALUE field is moot until if/when we want to support FCP-x error
detection and recovery for bidirectional commands. 
I believe we can allow recovery for bidirectional SCSI commands using
the additional information
in the E_STAT field in the REC and the information in the SRR.	It would
take a bit of work,
but it should not be too demanding an exercise since bidirectional
commands are required
to complete one transfer before starting the other, simplifying the
requirements significantly.
SRR may need another bit or two added.	The only reason we didn't do it
in the earlier revisions
was that bidirectional SCSI commands were added late in one of the FCP-x
documents and
nobody has bothered to revisit the retry processes with such commands in
mind.
Regarding Data Overlay:
The reference to SAM-3 is not intended to refer the reader to SAM-3 for
data overlay, but since it is outside the sentence this is what it
means. The reference will be removed since it provides value in this
context (i.e., the intent was to refer the reader to SAM-3 for
application client buffer offset but that is already covered).
The other two questions are vendor implementation specifc in my mind,
others may share if they wish... 
 Agreed.  See above.


From dickens at us.ibm.com  Tue May  2 05:43:45 2006
From: dickens at us.ibm.com (Lou Dickens)
Date: Tue, 2 May 2006 05:43:45 -0700
Subject: [T11.3] Wow there is a name I have not seen for awhile
Message-ID: <mailman.427.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0605020_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0605020_1f540764.jpg">1f540764.jpg</A>
Attachment #2: <A HREF="r0605020_graycol.gif">graycol.gif</A>
Attachment #3: <A HREF="r0605020_pic28329.gif">pic28329.gif</A>
Attachment #4: <A HREF="r0605020_ecblank.gif">ecblank.gif</A>

We what happens when you post to the reflector, you never know how will

harass you.. How have you been ?  Are they keeping you busy ?

 Lou Dickens						 

 Software Engineer					 

 9000 South Rita Road					 

 Tucson, Az, 85744					 

 Tel: 520-799-4139 (T/L: 321-4139)			 

 Fax: 520-799-5607:					 

 Email address: dickens at us.ibm.com			 

 http://www-03.ibm.com/servers/storage/ 		 

	     Gary.Franco at Emule						   

	     x.Com							   

	     Sent by:							To 

	     owner-t10 at t10.org	       <David.Peterson at mcdata.com>,	   

				       <t10 at t10.org>, <t11_3 at t11.org>	   

									cc 

	     05/01/2006 12:56	       <Bob.Nixon at Emulex.Com>		   

	     PM 						   Subject 

				       RE: FCP-4: Items for discussion	   

From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David

Peterson

Sent: Monday, May 01, 2006 2:23 PM

To: t10 at t10.org; t11_3 at t11.org

Subject: FCP-4: Items for discussion

Howdy,

Below is an email thread from Claudio that was discussed a bit at the last

FCP-4 working group meeting:

I please ask you to discuss in the FCP-4 WG the possibility to mandate

continuous increasing SEQ_CNT in FCP-4. Relying on it greatly simplifies

the detection of a missing Sequence and consequently simplifies error

recovery, but today is optional in FCP-x (while is mandated by IP over FC

and is going to be mandated by FC-SATA).

Additional items for FCP-4 discussion follows (all due to doubts submitted

to me...):

- Bidirectional Commands: I think we need to count bytes for both data-in

and data-out. Which of these two counters should be put in the FC4VALUE

field of the REC ELS?

Wouldn???t that be dependant on the type of command? FCP read or write types.
The device knows the current command type.

- Data Overlay: the FCP-3 definition of data overlay says "see SAM-3", but

SAM-3 says nothing on data overlay.

I would say that EMDP should be disabled cause with the end to end data

protection I do not think you can even enable this option because the DIFs

would get corrupted would they not?

- Data Overlay: In which way could it be possible detecting a missing

Sequence when data overlay is used and continuously increasing SEQ_CNT is

not used? (it seems to us that there is no way, but others may have a

different opinion...).

I agree, I think there is no possible way, at least real-time as the data

is being streamed in. At FCP response time the overrun/underrun and

residual length would cause a re-execution of the command.

- Data Overlay: how can the FC4VALUE counters can be accurate when data

overlap (i.e., how to avoid to count twice the overlapping data)?

I would think that the ability to resend data blocks already sent was

discussed in the specification as a bad thing. If not then I believe the

only way to catch a misbehaving target would be to track the data blocks

already received and keep track of the holes left behind. The device would

also have to track the resent data and not include the resent data as data

received to satisfy a read command.

The members of the working group came to no real concensus/resolution per

the questions and would like to open up the discussion to the T10/T11

commitees, specifically making Continuously Increasing SEQ_CNT a

requirement for FCP-4.

Making this a requirement would be a much need improvement, and one that

has been needed for a while.

Regarding Continuously Increasing SEQ_CNT:

We have discussed requiring Continuously Increasing SEQ_CNT during each

previous FCP-x standard development efforts and folk opted to not specify

it as a requirement since some vendors did not yet fully support it. We may

have now moved past that issue.

Regarding Bidirectional Commands:

FCP-3 states: "Sequence level error recovery as described in 12.4 shall not

be used for bidirectional SCSI commands." So the question regarding the

FC4VALUE field is moot until if/when we want to support FCP-x error

detection and recovery for bidirectional commands.

Regarding Data Overlay:

The reference to SAM-3 is not intended to refer the reader to SAM-3 for

data overlay, but since it is outside the sentence this is what it means.

The reference will be removed since it provides value in this context

(i.e., the intent was to refer the reader to SAM-3 for application client

buffer offset but that is already covered).

The other two questions are vendor implementation specifc in my mind,

others may share if they wish...

Thanks...Dave

(no disclaimer)



From dickens at us.ibm.com  Tue May  2 05:43:45 2006
From: dickens at us.ibm.com (Lou Dickens)
Date: Tue, 2 May 2006 05:43:45 -0700
Subject: Wow there is a name I have not seen for awhile
Message-ID: <mailman.428.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0605021_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0605021_1f540764.jpg">1f540764.jpg</A>
Attachment #2: <A HREF="r0605021_graycol.gif">graycol.gif</A>
Attachment #3: <A HREF="r0605021_pic28329.gif">pic28329.gif</A>
Attachment #4: <A HREF="r0605021_ecblank.gif">ecblank.gif</A>

We what happens when you post to the reflector, you never know how will

harass you.. How have you been ?  Are they keeping you busy ?

 Lou Dickens						 

 Software Engineer					 

 9000 South Rita Road					 

 Tucson, Az, 85744					 

 Tel: 520-799-4139 (T/L: 321-4139)			 

 Fax: 520-799-5607:					 

 Email address: dickens at us.ibm.com			 

 http://www-03.ibm.com/servers/storage/ 		 

	     Gary.Franco at Emule						   

	     x.Com							   

	     Sent by:							To 

	     owner-t10 at t10.org	       <David.Peterson at mcdata.com>,	   

				       <t10 at t10.org>, <t11_3 at t11.org>	   

									cc 

	     05/01/2006 12:56	       <Bob.Nixon at Emulex.Com>		   

	     PM 						   Subject 

				       RE: FCP-4: Items for discussion	   

From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David

Peterson

Sent: Monday, May 01, 2006 2:23 PM

To: t10 at t10.org; t11_3 at t11.org

Subject: FCP-4: Items for discussion

Howdy,

Below is an email thread from Claudio that was discussed a bit at the last

FCP-4 working group meeting:

I please ask you to discuss in the FCP-4 WG the possibility to mandate

continuous increasing SEQ_CNT in FCP-4. Relying on it greatly simplifies

the detection of a missing Sequence and consequently simplifies error

recovery, but today is optional in FCP-x (while is mandated by IP over FC

and is going to be mandated by FC-SATA).

Additional items for FCP-4 discussion follows (all due to doubts submitted

to me...):

- Bidirectional Commands: I think we need to count bytes for both data-in

and data-out. Which of these two counters should be put in the FC4VALUE

field of the REC ELS?

Wouldn???t that be dependant on the type of command? FCP read or write types.
The device knows the current command type.

- Data Overlay: the FCP-3 definition of data overlay says "see SAM-3", but

SAM-3 says nothing on data overlay.

I would say that EMDP should be disabled cause with the end to end data

protection I do not think you can even enable this option because the DIFs

would get corrupted would they not?

- Data Overlay: In which way could it be possible detecting a missing

Sequence when data overlay is used and continuously increasing SEQ_CNT is

not used? (it seems to us that there is no way, but others may have a

different opinion...).

I agree, I think there is no possible way, at least real-time as the data

is being streamed in. At FCP response time the overrun/underrun and

residual length would cause a re-execution of the command.

- Data Overlay: how can the FC4VALUE counters can be accurate when data

overlap (i.e., how to avoid to count twice the overlapping data)?

I would think that the ability to resend data blocks already sent was

discussed in the specification as a bad thing. If not then I believe the

only way to catch a misbehaving target would be to track the data blocks

already received and keep track of the holes left behind. The device would

also have to track the resent data and not include the resent data as data

received to satisfy a read command.

The members of the working group came to no real concensus/resolution per

the questions and would like to open up the discussion to the T10/T11

commitees, specifically making Continuously Increasing SEQ_CNT a

requirement for FCP-4.

Making this a requirement would be a much need improvement, and one that

has been needed for a while.

Regarding Continuously Increasing SEQ_CNT:

We have discussed requiring Continuously Increasing SEQ_CNT during each

previous FCP-x standard development efforts and folk opted to not specify

it as a requirement since some vendors did not yet fully support it. We may

have now moved past that issue.

Regarding Bidirectional Commands:

FCP-3 states: "Sequence level error recovery as described in 12.4 shall not

be used for bidirectional SCSI commands." So the question regarding the

FC4VALUE field is moot until if/when we want to support FCP-x error

detection and recovery for bidirectional commands.

Regarding Data Overlay:

The reference to SAM-3 is not intended to refer the reader to SAM-3 for

data overlay, but since it is outside the sentence this is what it means.

The reference will be removed since it provides value in this context

(i.e., the intent was to refer the reader to SAM-3 for application client

buffer offset but that is already covered).

The other two questions are vendor implementation specifc in my mind,

others may share if they wish...

Thanks...Dave

(no disclaimer)



From lohmeyer at t10.org  Tue May  2 13:22:58 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 02 May 2006 14:22:58 -0600
Subject: SAS Open House registration
Message-ID: <mailman.429.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Alice Tate is concerned that some people attending the T10 meetings next week
may not have registered to attend the SAS Open House on Tuesday evening. If
you haven't registered, then you will not have a pre-printed badge and there
may not be enough food/drink. Enough said? The URL to register is:
  http://www.scsita.org/news_events/SAS_OpenHouse_Reg.html 
Thanks!
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Tue May  2 14:40:38 2006
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Tue, 2 May 2006 16:40:38 -0500
Subject: SAS Open House registration
Message-ID: <mailman.430.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I think I am registered. Is there a way to check for sure, or should I just
register again?
	     John Lohmeyer						   
	     <lohmeyer at t10.org						   
	     >								To 
	     Sent by:		       T10 Reflector <t10 at t10.org>	   
	     owner-t10 at t10.org						cc 
	     No Phone Info	       Alice Tate <alice at scsita.org>	   
	     Available						   Subject 
				       SAS Open House registration	   
	     05/02/2006 03:22						   
	     PM 							   
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Alice Tate is concerned that some people attending the T10 meetings next
week may not have registered to attend the SAS Open House on Tuesday
evening. If you haven't registered, then you will not have a pre-printed
badge and there may not be enough food/drink. Enough said? The URL to
register is:
  http://www.scsita.org/news_events/SAS_OpenHouse_Reg.html
Thanks!
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Tue May  2 18:10:35 2006
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 2 May 2006 18:10:35 -0700
Subject: SSC-3: Secure Data Erase
Message-ID: <mailman.431.1441607308.22510.t10@sandbox.t10.org>

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

All,
I have updated the Secure Data Erase proposal.	It can be found at:
   http://www.t10.org/ftp/t10/document.06/06-120r2.pdf
within 30 minutes.
Paul,
Thank you for your quick review.  I have been working on your questions 
and have generated another revision of the proposal.
I really appreciate your time and efforts.  I ended up splitting out an 
overloaded function from the previous proposal and I think that cleaned up 
a lot of your issues.  For some others I am less sure, you will have to 
see how well this update addresses them.
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/ 
"Paul Entzel" <Paul.Entzel at Quantum.com> 
04/25/2006 07:43 AM
To
Kevin D Butt/Tucson/IBM at IBMUS, "Erich Oetting" 
<erich_oetting at stortek.com>, "Greg Wheeless" <greg.wheeless at veritas.com>, 
"BANTHER,MICHAEL \(HP-UnitedKingdom,ex2\)" <michael.banther at hp.com>, "Paul 
Suhler" <Paul.Suhler at Quantum.com>, "Peterson, David" 
<David.Peterson at McData.com>, <roger.cummings at symantec.com>
cc
<t10 at t10.org>
Subject
RE: SSC-3: Secure Data Erase
Kevin,
I took a couple of minutes to review the document and added a couple of 
notes.	I concentrated mainly on the ERASE(6) command since my devices 
only support this one.	I think my main area of concern is how these new 
bits will be handled by devices that do not check reserved fields in CDBs 
and also do not support these new bits.  Normally, I would not be all that 
concerned with this, except for the location you chose for the bits.  You 
placed the bits in the most significant 2 bits of byte 1, a location 
traditionally reserved since it used to hold the LUN field way back in 
SCSI-2 days.  In many of our devices, we zero out these bits to avoid 
problems with systems that put the LUN into the CDB.  That means these 
devices will not see the new bits and treat the ERASE command as if they 
were not set.  We can certainly change this behavior in future devices, 
but how is the application client to know if the bits are supported, 
checked, or ignored?
Paul Entzel
Quantum
-----Original Message-----
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Monday, April 24, 2006 11:31 PM
To: Erich Oetting; Greg Wheeless; BANTHER,MICHAEL (HP-UnitedKingdom,ex2); 
Paul Entzel; Paul Suhler; Peterson, David; roger.cummings at symantec.com
Cc: t10 at t10.org
Subject: SSC-3: Secure Data Erase
Tape Heads, 
I have posted a new version of the Secure Data Erase proposal.	I am 
hoping to get this through this meeting cycle.	Can you review and provide 
feedback? 
  http://www.t10.org/ftp/t10/document.06/06-120r1.pdf
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/ [attachment "06-120r1.pdf" deleted 
by Kevin D Butt/Tucson/IBM] 


From matt.ball at quantum.com  Thu May  4 10:48:01 2006
From: matt.ball at quantum.com (Matt Ball)
Date: Thu, 4 May 2006 11:48:01 -0600
Subject: SSC-3: T10/06-225r0 posted (Using NIST AES Key-Wrap for Key Establishment)
Message-ID: <mailman.432.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Matt Ball" <matt.ball at quantum.com>
*
Hi Everyone,
I've posted a proposal for wrapping the encrypting key as it passes across
the interface.	The main purpose of this proposal is to provide a FIPS
140-2-approved method for establishing encryption keys within the device
server.  This builds on Paul Entzel's 06-172r1 (key management) proposal, and
complements David Black's 06-103r1 proposal.
Please send me any comments.  I'd like to discuss this proposal this Tuesday
during the SSC-3 meeting in San Jose.
Thanks,
Matt Ball
Embedded Software Engineer
Quantum Corporation
4001 Discovery Drive, Suite 1100
Boulder, CO 80303
(720) 406-5766
-----Original Message-----
From: jlohmeye at scsibbs.co.lsil.com
[mailto:jlohmeye at scsibbs.co.lsil.com]On Behalf Of T10 Document
Administrator
Sent: Thursday, May 04, 2006 9:20 AM
To: Matt Ball
Subject: Re: RE: T10 Document Number Assigned (T10/06-225r0)
2006/05/04 09:20:15 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.06/06-225r0.pdf
Source File(s) that will be archived are:
   06-225r0.doc will be archived as 06-225r0.doc
Normally, the posting/archiving process takes about 30 minutes.
*
* 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 May  6 23:00:45 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 7 May 2006 00:00:45 -0600
Subject: Recent T10 documents uploaded since 2006/04/30
Message-ID: <mailman.433.1441607308.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 Wide port simultaneous connection rules
(by: Rob Elliott)
T10/05-322r3   Uploaded: 2006/05/04   55257 bytes
ftp://ftp.t10.org/t10/document.05/05-322r3.pdf
SAS-2 Multiplexing
(by: Rob Elliott)
T10/05-381r3   Uploaded: 2006/05/02   716273 bytes
ftp://ftp.t10.org/t10/document.05/05-381r3.pdf
SMC-3 Clarification SEND VOLUME TAG command
(by: Noud Snelder)
T10/05-414r2   Uploaded: 2006/05/04   84723 bytes
ftp://ftp.t10.org/t10/document.05/05-414r2.pdf
SAS-2 SMP Lists (DISCOVER LIST)
(by: Steve Johnson)
T10/06-037r5   Uploaded: 2006/05/02   113945 bytes
ftp://ftp.t10.org/t10/document.06/06-037r5.pdf
NWIP FCP-3
(by: Gary S. Robinson)
T10/06-045r1   Uploaded: 2006/05/05   26617 bytes
ftp://ftp.t10.org/t10/document.06/06-045r1.pdf
SAS-2 Expander Routing Table (REPORT EXPANDER ROUTE TABLE)
(by: Steve Johnson)
T10/06-078r1   Uploaded: 2006/05/01   93697 bytes
ftp://ftp.t10.org/t10/document.06/06-078r1.pdf
SSC-3: Secure Data Erase
(by: Kevin Butt)
T10/06-120r2   Uploaded: 2006/05/02   80413 bytes
ftp://ftp.t10.org/t10/document.06/06-120r2.pdf
Results of Letter Ballot on forwarding MMC-5  to first public review
(by: John Lohmeyer)
T10/06-185r0   Uploaded: 2006/05/04   112130 bytes
ftp://ftp.t10.org/t10/document.06/06-185r0.pdf
Results of Letter Ballot on forwarding MMC-5  to first public review
(by: John Lohmeyer)
T10/06-185r0   Uploaded: 2006/05/04   41440 bytes
ftp://ftp.t10.org/t10/document.06/06-185r0.txt
SPC-4 Request for the reservation/assignment of Security Protocol
value
(by: Avraham Shimor)
T10/06-191r2   Uploaded: 2006/05/02   16163 bytes
ftp://ftp.t10.org/t10/document.06/06-191r2.pdf
SAS-2 SMP CONFIGURE ZONE PERMISSION function
(by: Tim Symons)
T10/06-202r2   Uploaded: 2006/05/02   74103 bytes
ftp://ftp.t10.org/t10/document.06/06-202r2.pdf
SAS-2 SMP REPORT ZONE PERMISSION function
(by: Tim Symons)
T10/06-203r2   Uploaded: 2006/05/02   71275 bytes
ftp://ftp.t10.org/t10/document.06/06-203r2.pdf
SAS-2 REPORT GENERAL additions for zoning and self configuration
(by: Steve Johnson)
T10/06-213r0   Uploaded: 2006/05/03   67531 bytes
ftp://ftp.t10.org/t10/document.06/06-213r0.pdf
SAS-2 Expander Route Table (CONFIGURE EXPANDER ROUTE TABLE)
(by: Steve Johnson)
T10/06-214r0   Uploaded: 2006/05/01   83104 bytes
ftp://ftp.t10.org/t10/document.06/06-214r0.pdf
SAS-2 Zone managment proxy device
(by: Tim Symons)
T10/06-215r1   Uploaded: 2006/05/02   67033 bytes
ftp://ftp.t10.org/t10/document.06/06-215r1.pdf
SAT - Block Mapping Issues
(by: Robert Sheffield)
T10/06-216r0   Uploaded: 2006/05/01   21963 bytes
ftp://ftp.t10.org/t10/document.06/06-216r0.pdf
IR Status Report for May 2006
(by: Gary S. Robinson)
T10/06-217r0   Uploaded: 2006/05/02   13121 bytes
ftp://ftp.t10.org/t10/document.06/06-217r0.pdf
ADC-2 Clarification of MOUNTED
(by: Michael Banther)
T10/06-218r0   Uploaded: 2006/05/03   54986 bytes
ftp://ftp.t10.org/t10/document.06/06-218r0.pdf
SPC-4 New ASC/ASCQ  for LOGICAL UNIT ACCESS NOT AUTHORIZED
(by: Avraham Shimor)
T10/06-219r0   Uploaded: 2006/05/02   14145 bytes
ftp://ftp.t10.org/t10/document.06/06-219r0.pdf
SPC-4 Informational designator for Device Information VPD page
(by: Rob Elliott)
T10/06-221r0   Uploaded: 2006/05/03   26674 bytes
ftp://ftp.t10.org/t10/document.06/06-221r0.pdf
ADC-2 Add supported operation codes to caching
(by: Michael Banther)
T10/06-222r0   Uploaded: 2006/05/04   55951 bytes
ftp://ftp.t10.org/t10/document.06/06-222r0.pdf
ADC-2, SPC-4, and SSC-3 Vendor-specific service actions for
MAINTENANCE IN/OUT
(by: Michael Banther)
T10/06-223r0   Uploaded: 2006/05/04   64891 bytes
ftp://ftp.t10.org/t10/document.06/06-223r0.pdf
SPC-4: Change 'medium changer' to 'media changer'
(by: Paul Entzel)
T10/06-224r0   Uploaded: 2006/05/04   19327 bytes
ftp://ftp.t10.org/t10/document.06/06-224r0.pdf
SSC-3: Using NIST AES Key-Wrap for Key Establishment
(by: Matt Ball)
T10/06-225r0   Uploaded: 2006/05/04   161503 bytes
ftp://ftp.t10.org/t10/document.06/06-225r0.pdf
ADC-2 Add Encrypting field in VHF data
(by: Noud Snelder)
T10/06-226r0   Uploaded: 2006/05/04   13523 bytes
ftp://ftp.t10.org/t10/document.06/06-226r0.pdf
Agenda: ADI Meeting (8 May 2006)
(by: Michael Banther)
T10/06-227r0   Uploaded: 2006/05/04   9548 bytes
ftp://ftp.t10.org/t10/document.06/06-227r0.pdf
Minutes of SAS PHY Working Group conference call - April 20, 2006
(by: Alvin Cox)
T10/06-229r0   Uploaded: 2006/05/04   20367 bytes
ftp://ftp.t10.org/t10/document.06/06-229r0.pdf
Working Drafts
--------------
Fibre Channel Protocol - 4 (FCP-4)
(Editor: Dave Peterson)
 Rev: 00       Uploaded: 2006/05/01   896556 bytes
ftp://ftp.t10.org/t10/drafts/fcp4/fcp4r00.pdf
SCSI Media Changer Command Set - 3 (SMC-3)
(Editor: Noud Snelder)
 Rev: 02       Uploaded: 2006/05/03   1601026 bytes
ftp://ftp.t10.org/t10/drafts/smc3/smc3r02.pdf
(Report generated on 2006/05/07 at 00:00:44)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Sun May  7 19:40:50 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Sun, 07 May 2006 20:40:50 -0600
Subject: T10.org is back up
Message-ID: <mailman.434.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Actually, t10.org was never down. The internet connection into LSI Logic's
Colorado Springs data center was down from Friday morning until Sunday
afternoon. This made www.t10.org inaccessible to virtually everyone
(including most people inside LSI Logic because of the way our proxy.pac
routes our requests).
Hopefully, the internet connection will stay up (at least until T10 week is
over).
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From rwkembel at nlabooks.com  Wed May 10 08:19:27 2006
From: rwkembel at nlabooks.com (Robert Kembel)
Date: Wed, 10 May 2006 11:19:27 -0400
Subject: 05-322r3 SAS-2 Wide port simultaneous connection rules
Message-ID: <mailman.435.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Robert Kembel" <rwkembel at nlabooks.com>
*
Hi All,
In reading through this discussion, I had a question about Figure 2. In the
figure, it states:
"h) Port Z should not attempt to open more than 4 connections to port D"
Shouldn't this say 1 connection based on the single link between expander W
and Y?
Bob
Robert W. Kembel
Northwest Learning Associates, Inc.
13 Magnolia Circle
White River Junction, VT  05001
802-295-5647, FAX: 802-295-5649
Visit our web site at  <http://www.nlabooks.com/&gt; www.NLAbooks.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  Wed May 10 09:49:09 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 10 May 2006 10:49:09 -0600
Subject: SAS Protocol WG minutes posted
Message-ID: <mailman.436.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The draft SAS Protocol WG minutes are available at:
   http://www.t10.org/ftp/t10/document.06/06-230r1.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 michael.banther at hp.com  Wed May 10 10:45:56 2006
From: michael.banther at hp.com (Banther, Michael)
Date: Wed, 10 May 2006 18:45:56 +0100
Subject: ADI-2 Minutes available
Message-ID: <mailman.437.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0605102_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0605102_banthermichae.vcf">banthermichae.vcf</A>

The draft minutes of the 8 May 2006 ADI-2 working group meeting have
been posted at http://www.t10.org/ftp/t10/document.06/06-228r0.pdf.
Regards,
Michael Banther
Hewlett-Packard Ltd.
Telephone +44 (117) 312-9503


From Alvin.Cox at seagate.com  Wed May 10 11:09:01 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 10 May 2006 13:09:01 -0500
Subject: SAS PHY WG minutes posted
Message-ID: <mailman.438.1441607308.22510.t10@sandbox.t10.org>

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

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


From kdbutt at us.ibm.com  Wed May 10 17:09:30 2006
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 10 May 2006 17:09:30 -0700
Subject: 06-113r2 (SPC-4: Log Page-Subpages) posted
Message-ID: <mailman.439.1441607308.22510.t10@sandbox.t10.org>

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

2006/05/10 16:20:16 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.06/06-113r2.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From kdbutt at us.ibm.com  Wed May 10 17:05:24 2006
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 10 May 2006 17:05:24 -0700
Subject: 06-120r3 (Secure Data Erase) has been posted
Message-ID: <mailman.440.1441607308.22510.t10@sandbox.t10.org>

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

2006/05/10 17:10:25 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.06/06-120r3.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From kdbutt at us.ibm.com  Wed May 10 17:10:36 2006
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 10 May 2006 17:10:36 -0700
Subject: 06-244r0 (Minutes: SSC-3: 09 May) posted
Message-ID: <mailman.441.1441607308.22510.t10@sandbox.t10.org>

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

2006/05/10 16:20:16 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/ftp/t10/document.06/06-244r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From Vit.Novak at SFBay.Sun.COM  Thu May 11 17:42:35 2006
From: Vit.Novak at SFBay.Sun.COM (Vit Novak)
Date: Thu, 11 May 2006 17:42:35 -0700
Subject: Toshiba AC Adaptor
Message-ID: <mailman.442.1441607308.22510.t10@sandbox.t10.org>

i apologize for this wide distribution but I forgot my laptop AC adaptor
model Toshiba PA2450U in the Empire CR last night (5/10) after the SFF
meeting around 6PM. It was not turned in at the hotel. If somebody knows
of its whereabouts, please let me know.
Thanks,
Vit Novak
Sun Microsystems, Inc.
7777 Gateway Blvd, 
Newark, CA 94560
Telephone +1 (510) 936-3284
vit.novak at sun.com


From roger_cummings at symantec.com  Thu May 11 17:16:08 2006
From: roger_cummings at symantec.com (Roger Cummings)
Date: Thu, 11 May 2006 20:16:08 -0400
Subject: SMC  minutes posted as 06-239r0
Message-ID: <mailman.443.1441607308.22510.t10@sandbox.t10.org>

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

Folks,
The minutes of the SMC Working Group were posted yesterday as 06-239r0.
The URL for the document is:
http://www.t10.org/ftp/t10/document.06/06-239r0.pdf
Regards,
Roger Cummings
SYMANTEC
roger_cummings at symantec.com


From Vit.Novak at Sun.COM  Thu May 11 17:42:35 2006
From: Vit.Novak at Sun.COM (Vit Novak)
Date: Thu, 11 May 2006 17:42:35 -0700
Subject: Toshiba AC Adaptor
Message-ID: <mailman.444.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Vit Novak <Vit.Novak at Sun.COM>
*
i apologize for this wide distribution but I forgot my laptop AC adaptor
model Toshiba PA2450U in the Empire CR last night (5/10) after the SFF
meeting around 6PM. It was not turned in at the hotel. If somebody knows
of its whereabouts, please let me know.
Thanks,
Vit Novak
Sun Microsystems, Inc.
7777 Gateway Blvd, 
Newark, CA 94560
Telephone +1 (510) 936-3284
vit.novak at sun.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From takeshi_kohda at post.pioneer.co.jp  Thu May 11 20:49:02 2006
From: takeshi_kohda at post.pioneer.co.jp (takeshi_kohda at post.pioneer.co.jp)
Date: Fri, 12 May 2006 12:49:02 +0900
Subject: Minutes of May Mt. Fuji meeting
Message-ID: <mailman.445.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* takeshi_kohda at post.pioneer.co.jp
*
May Mt. Fuji meeting minutes have been posted on the fuji ftp site.
ftp://ftp.avc-pioneer.com/Mtfuji_7/Minutes/MinMay06.pdf
Best regards,
---
Takeshi Kohda
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From t10 at RichRamos.com  Fri May 12 10:43:11 2006
From: t10 at RichRamos.com (Rich Ramos)
Date: Fri, 12 May 2006 10:43:11 -0700
Subject: SPC-4: PR Annex B question
Message-ID: <mailman.446.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Rich Ramos <t10 at RichRamos.com>
*
I just want to make sure as I did a quick search and haven't seen 
this discussed on the reflector....
In Annex B, B.1 second sentence:
"The PERSISTENT RESERVE IN command is used to replace any feature of 
the reserve/release management method."
there is supposed to be a "not" in there isn't there?
As in:
The PERSISTENT RESERVE IN command is *not* used to replace any 
feature of the reserve/release management method.
-Rich
*
* 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  Fri May 12 11:14:31 2006
From: MOverby at nvidia.com (Mark Overby)
Date: Fri, 12 May 2006 11:14:31 -0700
Subject: SAT Working Group Minutes posted
Message-ID: <mailman.447.1441607308.22510.t10@sandbox.t10.org>

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

06-231r0 - in the usual locations.
-----------------------------------------------------------------------------
------
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 kdbutt at us.ibm.com  Fri May 12 15:18:40 2006
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 12 May 2006 15:18:40 -0700
Subject: Encryption Algorithm Identifier
Message-ID: <mailman.448.1441607308.22510.t10@sandbox.t10.org>

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

All,
For Encryption the suggestion has been made that it might be better to use 
the algorithm identifier from PKCS than the Security identifier that we 
just voted on in CAP.  It is a variable length self describing format from 
the Public Key Cryptography Standards (PKCS).
ASN.1 AlgorithmIdentifier from PKCS  (OID's)
ASN.1 - Abstract Syntax Notation One
OID - Object Identifier
Any thoughts?  If it does make better sense a change would have to be made 
very rapidly so we don't get implementations and can remove what we 
already put in.
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 daviburg at windows.microsoft.com  Fri May 12 15:35:16 2006
From: daviburg at windows.microsoft.com (David Burg)
Date: Fri, 12 May 2006 15:35:16 -0700
Subject: Minutes of May Mt. Fuji meeting
Message-ID: <mailman.449.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "David Burg" <daviburg at windows.microsoft.com>
*
Dear Kohda-san,
Could you share to the members of the reflector the documents
distributed at the meeting, especially the HD DVD-R DL?
Thank you!
Best regards,
David Burg.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of
takeshi_kohda at post.pioneer.co.jp
Sent: Thursday, May 11, 2006 8:49 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org
Subject: Minutes of May Mt. Fuji meeting
May Mt. Fuji meeting minutes have been posted on the fuji ftp site.
ftp://ftp.avc-pioneer.com/Mtfuji_7/Minutes/MinMay06.pdf
Best regards,
---
Takeshi Kohda
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From rsnively at Brocade.COM  Fri May 12 17:57:20 2006
From: rsnively at Brocade.COM (Robert Snively)
Date: Fri, 12 May 2006 17:57:20 -0700
Subject: Encryption Algorithm Identifier
Message-ID: <mailman.450.1441607308.22510.t10@sandbox.t10.org>

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

If it is necessary to define additional variants, INCITS now has a
registered
OID of which T11 is using one ARC.  T10 could use another ARC if the
one provided by PKC is not precisely applicable.
Bob
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Friday, May 12, 2006 3:19 PM
To: t10 at t10.org
Subject: Encryption Algorithm Identifier
All, 
For Encryption the suggestion has been made that it might be better to
use the algorithm identifier from PKCS than the Security identifier that
we just voted on in CAP.  It is a variable length self describing format
|from the Public Key Cryptography Standards (PKCS). 
ASN.1 AlgorithmIdentifier from PKCS  (OID's) 
ASN.1 - Abstract Syntax Notation One 
OID - Object Identifier 
Any thoughts?  If it does make better sense a change would have to be
made very rapidly so we don't get implementations and can remove what we
already put in. 
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 dmeyer at siliconstor.com  Sat May 13 00:24:11 2006
From: dmeyer at siliconstor.com (Dan Meyer)
Date: Sat, 13 May 2006 00:24:11 -0700
Subject: SPC-4: PR Annex B question
Message-ID: <mailman.451.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Dan Meyer" <dmeyer at siliconstor.com>
*
Rich,
	No, the wording is correct.  If you look at SPC-3 in the first
section (Scope) you will see that RESERVE/RELEASE was made obsolete by
that version.  SPC-2 had both types of the command.  That said, I
suspect that people are still making devices and writing software today
that support the original RESERVE/RELEASE.
Dan Meyer
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Rich
Ramos
Sent: Friday, May 12, 2006 10:43 AM
To: t10 at t10.org
Subject: SPC-4: PR Annex B question
* From the T10 Reflector (t10 at t10.org), posted by:
* Rich Ramos <t10 at RichRamos.com>
*
I just want to make sure as I did a quick search and haven't seen 
this discussed on the reflector....
In Annex B, B.1 second sentence:
"The PERSISTENT RESERVE IN command is used to replace any feature of 
the reserve/release management method."
there is supposed to be a "not" in there isn't there?
As in:
The PERSISTENT RESERVE IN command is *not* used to replace any 
feature of the reserve/release management method.
-Rich
*
* 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 t10 at RichRamos.com  Sat May 13 08:57:58 2006
From: t10 at RichRamos.com (Rich Ramos)
Date: Sat, 13 May 2006 08:57:58 -0700
Subject: SPC-4: PR Annex B question
Message-ID: <mailman.452.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Rich Ramos <t10 at RichRamos.com>
*
Hi Dan,
I'm not sure I follow the explanation.	I understand that 
RESERVE/RELEASE has been obsolesced in SPC-3.  In fact the Annex is 
there to help people with a minimum implementation of PR IN/OUT to 
give equivalent functionality of the old RESERVE/RELEASE.  And the 
old RESERVE/RELEASE had no mechanism for *reporting* reservations 
(well other than returning an error ;), which is what PR IN gives 
you.  That is why I believe that there should be a "not" in there 
since no such equivalent functionality in RESERVE/RELEASE.
-Rich
--- Original ---
From: Dan Meyer <dmeyer at siliconstor.com>
To: Rich Ramos <t10 at RichRamos.com>, t10 at t10.org
Date: 5/13/06 12:24 AM -0700
Subject: RE: SPC-4: PR Annex B question
* From the T10 Reflector (t10 at t10.org), posted by:
* "Dan Meyer" <dmeyer at siliconstor.com>
*
Rich,
	No, the wording is correct.  If you look at SPC-3 in the first
section (Scope) you will see that RESERVE/RELEASE was made obsolete
by that version.  SPC-2 had both types of the command.	That said, I
suspect that people are still making devices and writing software
today that support the original RESERVE/RELEASE.
Dan Meyer
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Rich
Ramos
Sent: Friday, May 12, 2006 10:43 AM
To: t10 at t10.org
Subject: SPC-4: PR Annex B question
* From the T10 Reflector (t10 at t10.org), posted by:
* Rich Ramos <t10 at RichRamos.com>
*
I just want to make sure as I did a quick search and haven't seen
this discussed on the reflector....
In Annex B, B.1 second sentence:
"The PERSISTENT RESERVE IN command is used to replace any feature
of  the reserve/release management method."
there is supposed to be a "not" in there isn't there?
As in:
The PERSISTENT RESERVE IN command is *not* used to replace any
feature of the reserve/release management method.
-Rich
*
* 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  Sat May 13 23:00:50 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 14 May 2006 00:00:50 -0600
Subject: Recent T10 documents uploaded since 2006/05/07
Message-ID: <mailman.453.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SES-2 Display element enhancements
(by: Rob Elliott)
T10/05-011r2   Uploaded: 2006/05/11   23600 bytes
ftp://ftp.t10.org/t10/document.05/05-011r2.pdf
ADI ADC-2 Target Device Serial Number subpage
(by: Rod Wideman)
T10/05-155r5   Uploaded: 2006/05/08   142822 bytes
ftp://ftp.t10.org/t10/document.05/05-155r5.pdf
SMC-3 REQUEST DATA TRANSFER ELEMENT INQUIRY command
(by: Rod Wideman)
T10/05-243r4   Uploaded: 2006/05/08   140377 bytes
ftp://ftp.t10.org/t10/document.05/05-243r4.pdf
SAS-2 Start-up training sequence
(by: Harvey Newman)
T10/05-397r3   Uploaded: 2006/05/08   4595216 bytes
ftp://ftp.t10.org/t10/document.05/05-397r3.pdf
SBC-3 Physical blocks
(by: Rob Elliott)
T10/06-034r3   Uploaded: 2006/05/10   252641 bytes
ftp://ftp.t10.org/t10/document.06/06-034r3.pdf
SBC-3 Physical blocks
(by: Rob Elliott)
T10/06-034r4   Uploaded: 2006/05/13   260837 bytes
ftp://ftp.t10.org/t10/document.06/06-034r4.pdf
SAS BROADCAST ASYNCHRONOUS EVENT
(by: Steven Fairchild)
T10/06-044r3   Uploaded: 2006/05/08   142918 bytes
ftp://ftp.t10.org/t10/document.06/06-044r3.pdf
ADI:  Features for ADC-2 and ADT-2
(by: Paul Suhler)
T10/06-060r1   Uploaded: 2006/05/08   134944 bytes
ftp://ftp.t10.org/t10/document.06/06-060r1.pdf
ADC-2 Model for Devices with No ADT Ports
(by: Paul Suhler)
T10/06-061r2   Uploaded: 2006/05/08   117498 bytes
ftp://ftp.t10.org/t10/document.06/06-061r2.pdf
SAS-2 SSC Investigation
(by: Barry Olawsky)
T10/06-064r2   Uploaded: 2006/05/09   193655 bytes
ftp://ftp.t10.org/t10/document.06/06-064r2.pdf
SPC-4: Add security protocol and additional sense for tape encryption
(by: Paul Entzel)
T10/06-108r3   Uploaded: 2006/05/10   18928 bytes
ftp://ftp.t10.org/t10/document.06/06-108r3.pdf
SPC-4: Log Page-Subpages
(by: Kevin Butt)
T10/06-113r2   Uploaded: 2006/05/10   130271 bytes
ftp://ftp.t10.org/t10/document.06/06-113r2.pdf
SAS-2 BREAK_REPLY
(by: Tim Hoglund)
T10/06-119r1   Uploaded: 2006/05/07   388416 bytes
ftp://ftp.t10.org/t10/document.06/06-119r1.pdf
SSC-3: Secure Data Erase
(by: Kevin Butt)
T10/06-120r3   Uploaded: 2006/05/10   74702 bytes
ftp://ftp.t10.org/t10/document.06/06-120r3.pdf
SAT revision 8 letter ballot comment resolution as of SATr08
(by: Robert Sheffield)
T10/06-121r1   Uploaded: 2006/05/08   4491604 bytes
ftp://ftp.t10.org/t10/document.06/06-121r1.fdf
SAT revision 8 letter ballot comment resolution as of SATr08
(by: Robert Sheffield)
T10/06-121r1   Uploaded: 2006/05/08   5825518 bytes
ftp://ftp.t10.org/t10/document.06/06-121r1.pdf
Key Encryption as per T10/06-103
(by: David L. Black)
T10/06-144r1   Uploaded: 2006/05/10   93346 bytes
ftp://ftp.t10.org/t10/document.06/06-144r1.pdf
Minutes of SMC-3 Conference Call - March 27, 2006
(by: Roger Cummings)
T10/06-174r1   Uploaded: 2006/05/08   18363 bytes
ftp://ftp.t10.org/t10/document.06/06-174r1.pdf
SAS-2 BROADCAST processing clarifications
(by: Ed D'Avignon and Rob Elliott)
T10/06-177r3   Uploaded: 2006/05/13   117167 bytes
ftp://ftp.t10.org/t10/document.06/06-177r3.pdf
ADC-2: Reporting Microcode download in progress thru DT Activity and
other fixes
(by: Bianca Tudosa, Veronica Hernandez and Kevin Marks)
T10/06-180r1   Uploaded: 2006/05/12   48275 bytes
ftp://ftp.t10.org/t10/document.06/06-180r1.pdf
SMC-3: Diagnostic and statistics log pages for SMC
(by: Gary Lestage and Kevin Marks)
T10/06-182r0   Uploaded: 2006/05/08   62066 bytes
ftp://ftp.t10.org/t10/document.06/06-182r0.pdf
SPC-4 Persistent Reservation additional sense code changes
(by: Rob Elliott)
T10/06-195r1   Uploaded: 2006/05/11   28252 bytes
ftp://ftp.t10.org/t10/document.06/06-195r1.pdf
SAS-2 No BROADCASTs before link reset sequence completes
(by: Luben Tuikov, Rob Elliott)
T10/06-199r1   Uploaded: 2006/05/09   25479 bytes
ftp://ftp.t10.org/t10/document.06/06-199r1.pdf
SES-2 Internal/External Vendor Specific connectors
(by: George O. Penokie)
T10/06-200r1   Uploaded: 2006/05/11   63889 bytes
ftp://ftp.t10.org/t10/document.06/06-200r1.pdf
SAS-2 Data Eyes vs De-Emphasis
(by: Kevin Witt & Adrian Robinson)
T10/06-206r1   Uploaded: 2006/05/08   692887 bytes
ftp://ftp.t10.org/t10/document.06/06-206r1.pdf
SAS-2 Data Eyes vs De-Emphasis
(by: Kevin Witt & Adrian Robinson)
T10/06-206r2   Uploaded: 2006/05/09   954585 bytes
ftp://ftp.t10.org/t10/document.06/06-206r2.pdf
SAS-2: Reporting ZONE PARTICIPATING CAPABLE in the IDENTIFY address
frame
(by: Kevin Marks)
T10/06-210r0   Uploaded: 2006/05/07   36619 bytes
ftp://ftp.t10.org/t10/document.06/06-210r0.pdf
SAS-2 Zone Group of an Expander's SMP
(by: Ed D'Avignon)
T10/06-212r1   Uploaded: 2006/05/10   65271 bytes
ftp://ftp.t10.org/t10/document.06/06-212r1.pdf
IR Status Report for May 2006
(by: Gary S. Robinson)
T10/06-217r1   Uploaded: 2006/05/10   14472 bytes
ftp://ftp.t10.org/t10/document.06/06-217r1.pdf
IR Status Report for May 2006
(by: Gary S. Robinson)
T10/06-217r2   Uploaded: 2006/05/11   14422 bytes
ftp://ftp.t10.org/t10/document.06/06-217r2.pdf
ADC-2 Clarification of MOUNTED
(by: Michael Banther)
T10/06-218r1   Uploaded: 2006/05/10   55075 bytes
ftp://ftp.t10.org/t10/document.06/06-218r1.pdf
SPC-4 New ASC/ASCQs for LOGICAL UNIT ACCESS NOT AUTHORIZED
(by: Avraham Shimor)
T10/06-219r1   Uploaded: 2006/05/10   11305 bytes
ftp://ftp.t10.org/t10/document.06/06-219r1.pdf
T11 Liaison report, April 2006
(by: Robert Snively)
T10/06-220r0   Uploaded: 2006/05/07   12087 bytes
ftp://ftp.t10.org/t10/document.06/06-220r0.pdf
ADC-2, SPC-4, and SSC-3 Vendor-specific service actions for
MAINTENANCE IN/OUT
(by: Michael Banther)
T10/06-223r1   Uploaded: 2006/05/10   64950 bytes
ftp://ftp.t10.org/t10/document.06/06-223r1.pdf
SPC-4: Change 'medium changer' to 'media changer'
(by: Paul Entzel)
T10/06-224r1   Uploaded: 2006/05/10   19214 bytes
ftp://ftp.t10.org/t10/document.06/06-224r1.pdf
Minutes: ADI Meeting (8 May 2006)
(by: Michael Banther)
T10/06-228r0   Uploaded: 2006/05/10   28590 bytes
ftp://ftp.t10.org/t10/document.06/06-228r0.pdf
Minutes of SAS Protocol Working Group - May 8, 2006
(by: Weber & Lohmeyer)
T10/06-230r0   Uploaded: 2006/05/09   23016 bytes
ftp://ftp.t10.org/t10/document.06/06-230r0.htm
Minutes of SAS Protocol Working Group - May 8, 2006
(by: Weber & Lohmeyer)
T10/06-230r0   Uploaded: 2006/05/09   92849 bytes
ftp://ftp.t10.org/t10/document.06/06-230r0.pdf
Minutes of SAS Protocol Working Group - May 8, 2006
(by: Weber & Lohmeyer)
T10/06-230r1   Uploaded: 2006/05/10   23211 bytes
ftp://ftp.t10.org/t10/document.06/06-230r1.htm
Minutes of SAS Protocol Working Group - May 8, 2006
(by: Weber & Lohmeyer)
T10/06-230r1   Uploaded: 2006/05/10   92837 bytes
ftp://ftp.t10.org/t10/document.06/06-230r1.pdf
Minutes of SAT Working Group - May 9, 2006
(by: Mark Overby)
T10/06-231r0   Uploaded: 2006/05/12   128044 bytes
ftp://ftp.t10.org/t10/document.06/06-231r0.pdf
SAS-2 TCTF and Minimum Transmitter Amplitude
(by: Barry Olawsky)
T10/06-234r0   Uploaded: 2006/05/08   168548 bytes
ftp://ftp.t10.org/t10/document.06/06-234r0.pdf
ADC-2, SSC-3 Align clean notification names
(by: Michael Banther)
T10/06-235r0   Uploaded: 2006/05/08   67470 bytes
ftp://ftp.t10.org/t10/document.06/06-235r0.pdf
ADC-2, SSC-3 Align clean notification names
(by: Michael Banther)
T10/06-235r1   Uploaded: 2006/05/10   67749 bytes
ftp://ftp.t10.org/t10/document.06/06-235r1.pdf
FCP-4 Fix race condition between REC ACC and FCP_XFER_RDY
(by: Paul Entzel)
T10/06-236r0   Uploaded: 2006/05/08   14103 bytes
ftp://ftp.t10.org/t10/document.06/06-236r0.pdf
FCP-4: Necessity for S_ID in REC Payload
(by: Craig W. Carlson)
T10/06-237r0   Uploaded: 2006/05/08   14280 bytes
ftp://ftp.t10.org/t10/document.06/06-237r0.pdf
ADI-2 Working Group Report to Plenary, May 2006
(by: Paul Suhler)
T10/06-238r0   Uploaded: 2006/05/10   61407 bytes
ftp://ftp.t10.org/t10/document.06/06-238r0.pdf
Minutes of SMC Working Group - May 8, 2006
(by: Roger Cummings)
T10/06-239r0   Uploaded: 2006/05/10   31319 bytes
ftp://ftp.t10.org/t10/document.06/06-239r0.pdf
Trusted Computing Group Liaison Report
(by: Roger Cummings)
T10/06-240r0   Uploaded: 2006/05/10   110063 bytes
ftp://ftp.t10.org/t10/document.06/06-240r0.pdf
FCP-4: Working Group Agenda - May 9, 2006
(by: David Peterson)
T10/06-242r0   Uploaded: 2006/05/09   9555 bytes
ftp://ftp.t10.org/t10/document.06/06-242r0.pdf
Minutes of FCP-4 Working Group - May 9, 2006
(by: David Peterson)
T10/06-243r0   Uploaded: 2006/05/09   24288 bytes
ftp://ftp.t10.org/t10/document.06/06-243r0.pdf
Minutes: SSC-3: 09 May
(by: Kevin Butt)
T10/06-244r0   Uploaded: 2006/05/10   66986 bytes
ftp://ftp.t10.org/t10/document.06/06-244r0.pdf
SAS-2 TCTF Candidate Touchstone File
(by: Galen Fromm)
T10/06-245r0   Uploaded: 2006/05/09   10366053 bytes
ftp://ftp.t10.org/t10/document.06/06-245r0.s4p
Minutes of SAS Physical Working Group, May 9, 2006
(by: Alvin Cox)
T10/06-246r0   Uploaded: 2006/05/10   39308 bytes
ftp://ftp.t10.org/t10/document.06/06-246r0.pdf
SMC-3 May, 2006 Plenary Report
(by: Michael Banther)
T10/06-247r0   Uploaded: 2006/05/10   11727 bytes
ftp://ftp.t10.org/t10/document.06/06-247r0.pdf
Proposal to remove the PREVENT ALLOW MEDIUM REMOVAL (PAMR) command
|from SPC-4
(by: William P. McFerrin)
T10/06-248r0   Uploaded: 2006/05/10   9594 bytes
ftp://ftp.t10.org/t10/document.06/06-248r0.pdf
Proposal to remove the PREVENT ALLOW MEDIUM REMOVAL (PAMR) command
|from SPC-4
(by: William P. McFerrin)
T10/06-248r1   Uploaded: 2006/05/10   9772 bytes
ftp://ftp.t10.org/t10/document.06/06-248r1.pdf
Minutes: MMC WG Meeting Minutes 9-10 May 2006
(by: William P. McFerrin)
T10/06-249r0   Uploaded: 2006/05/11   16145 bytes
ftp://ftp.t10.org/t10/document.06/06-249r0.pdf
STA -T10 Liaison Report - May 11, 2006
(by: Marty Czekalski)
T10/06-251r0   Uploaded: 2006/05/10   211346 bytes
ftp://ftp.t10.org/t10/document.06/06-251r0.pdf
Remove PREVENT ALLOW MEDIUM REMOVAL from OSD-2
(by: Ralph O. Weber)
T10/06-257r0   Uploaded: 2006/05/11   18699 bytes
ftp://ftp.t10.org/t10/document.06/06-257r0.pdf
Working Drafts
--------------
SCSI Block Commands - 3 (SBC-3)
(Editor: George Penokie)
 Rev: 05       Uploaded: 2006/05/11   3727223 bytes
ftp://ftp.t10.org/t10/drafts/sbc3/sbc3r05.pdf
SCSI Enclosure Services - 2 (SES-2)
(Editor: Rob Elliott)
 Rev: 15       Uploaded: 2006/05/13   720812 bytes
ftp://ftp.t10.org/t10/drafts/ses2/ses2r15.pdf
SCSI Stream Commands - 3 (SSC-3)
(Editor: Dave Peterson)
 Rev: 02a      Uploaded: 2006/05/08   1012675 bytes
ftp://ftp.t10.org/t10/drafts/ssc3/ssc3r02a.pdf
(Report generated on 2006/05/14 at 00:00:49)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From takeshi_kohda at post.pioneer.co.jp  Mon May 15 01:20:33 2006
From: takeshi_kohda at post.pioneer.co.jp (takeshi_kohda at post.pioneer.co.jp)
Date: Mon, 15 May 2006 17:20:33 +0900
Subject: Minutes of May Mt. Fuji meeting
Message-ID: <mailman.454.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* takeshi_kohda at post.pioneer.co.jp
*
Dear David and all,
You may find the distributed documents of May Mt. Fuji meeting at the
following
url:
ftp://ftp.avc-pioneer.com/Mtfuji_7/Proposal/May06/
Kind regards,
---
Takeshi Kohda
2006/05/13 07:34, "David Burg" <daviburg at windows.microsoft.com> wrote:
>
> Dear Kohda-san,
>
> Could you share to the members of the reflector the documents
> distributed at the meeting, especially the HD DVD-R DL?
>
> Thank you!
>
> Best regards,
>
> David Burg.
>
> -----Original Message-----
> From: owner-mtfuji5 at avc-pioneer.com
> [mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of
> takeshi_kohda at post.pioneer.co.jp
> Sent: Thursday, May 11, 2006 8:49 PM
> To: mtfuji5 at avc-pioneer.com
> Cc: t10 at t10.org
> Subject: Minutes of May Mt. Fuji meeting
>
> May Mt. Fuji meeting minutes have been posted on the fuji ftp site.
>
> ftp://ftp.avc-pioneer.com/Mtfuji_7/Minutes/MinMay06.pdf
>
> Best regards,
> ---
> Takeshi Kohda
>
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at ieee.org  Mon May 15 06:21:54 2006
From: roweber at ieee.org (Ralph Weber)
Date: Mon, 15 May 2006 08:21:54 -0500
Subject: SPC-4: PR Annex B question
Message-ID: <mailman.455.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Rich,
Your observation about the missing 'not' is correct.
In the original 04-269r1 document, the sentence read:
"No PERSISTENT RESERVE IN functionality is required
to replace the reserve/release management method."
I edited it to the current text during incorporation
and apparently forgot the negative context.
I have made a note to add the 'not' in SPC-4 r05.
All the best,
.Ralph
Rich Ramos wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Rich Ramos <t10 at RichRamos.com>
> *
>
> Hi Dan,
>
> I'm not sure I follow the explanation.  I understand that 
> RESERVE/RELEASE has been obsolesced in SPC-3.  In fact the Annex is 
> there to help people with a minimum implementation of PR IN/OUT to 
> give equivalent functionality of the old RESERVE/RELEASE.  And the old 
> RESERVE/RELEASE had no mechanism for *reporting* reservations (well 
> other than returning an error ;), which is what PR IN gives you.  That 
> is why I believe that there should be a "not" in there since no such 
> equivalent functionality in RESERVE/RELEASE.
>
> -Rich
>
>
> --- Original ---
> From: Dan Meyer <dmeyer at siliconstor.com>
> To: Rich Ramos <t10 at RichRamos.com>, t10 at t10.org
> Date: 5/13/06 12:24 AM -0700
> Subject: RE: SPC-4: PR Annex B question
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Dan Meyer" <dmeyer at siliconstor.com>
> *
> Rich,
>
>     No, the wording is correct.  If you look at SPC-3 in the first
> section (Scope) you will see that RESERVE/RELEASE was made obsolete
> by that version.  SPC-2 had both types of the command.  That said, I
> suspect that people are still making devices and writing software
> today that support the original RESERVE/RELEASE.
>
>
>
>
> Dan Meyer
>
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Rich
> Ramos
> Sent: Friday, May 12, 2006 10:43 AM
> To: t10 at t10.org
> Subject: SPC-4: PR Annex B question
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Rich Ramos <t10 at RichRamos.com>
> *
>
> I just want to make sure as I did a quick search and haven't seen
> this discussed on the reflector....
>
> In Annex B, B.1 second sentence:
> "The PERSISTENT RESERVE IN command is used to replace any feature
> of  the reserve/release management method."
>
> there is supposed to be a "not" in there isn't there?
>
> As in:
> The PERSISTENT RESERVE IN command is *not* used to replace any
> feature of the reserve/release management method.
>
>
> -Rich
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Mon May 15 08:29:26 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 15 May 2006 09:29:26 -0600
Subject: CAP WG Minutes posted
Message-ID: <mailman.456.1441607308.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-232r0.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 daviburg at windows.microsoft.com  Mon May 15 19:33:32 2006
From: daviburg at windows.microsoft.com (David Burg)
Date: Mon, 15 May 2006 19:33:32 -0700
Subject: MMC: Tiny editorial issue in mmc5r03, BD-R POW and VCPS feature descriptors
Message-ID: <mailman.457.1441607308.22510.t10@sandbox.t10.org>

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

Hello,
"5.4.8 Profile 0008h: CD-ROM" is not consistent with other profiles "No
Current Profile (0000h)" (words ordering and brackets). Really, really
editorial only.
Also in BD-R POW and VCPS feature descriptors, did we have a good reason
to set an additional length of 4 despite all four bytes being reserved?
Best regards,
David Burg
Research Software Engineering Lead
Tel.: +1 425 707 8769


From keiji_katata at post.pioneer.co.jp  Mon May 15 21:37:13 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 16 May 2006 13:37:13 +0900
Subject: June Mt.Fuji meeting announcement
Message-ID: <mailman.458.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
This is June Mt.Fuji meeting announcement.
We have 2 days.
June 5 (Mon).
Pioneer Head office New annex Building
8F Large meeting room
Meguro Tokyo, Japan
June 6 (Tue)
Pioneer PAX Building
1-1 meeting room
Meguro Tokyo, Japan
For both days,
10:00 - 18:00.
(The entrance opens at 9:30 am)
Registration is required at the reception desk.
* Access information:
http://www.pioneer.co.jp/corp/profile/map/meguro/index-e.html
It will take 7 to 10 minutes by walk from Meguro station of JR
Yamanote-Line.
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  Mon May 15 23:30:21 2006
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Tue, 16 May 2006 15:30:21 +0900
Subject: Amendment: June Mt.Fuji meeting announcement
Message-ID: <mailman.459.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
The floor of the "June 5" is 7th (not 8th).
Here is the correct information.
June 5 (Mon).
Pioneer Head office New annex Building
7F Large meeting room
Meguro Tokyo, Japan
Best regards,
Keiji Katata
PIONEER CORP.
keiji_katata at post.pioneer.co.jp@avc-pioneer.com on 2006/05/16 13:37:13
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  mtfuji5 at avc-pioneer.com
cc:    t10 at t10.org
bcc:
$B7oL>(B:  June Mt.Fuji meeting announcement
Hello all,
This is June Mt.Fuji meeting announcement.
We have 2 days.
June 5 (Mon).
Pioneer Head office New annex Building
8F Large meeting room
Meguro Tokyo, Japan
June 6 (Tue)
Pioneer PAX Building
1-1 meeting room
Meguro Tokyo, Japan
For both days,
10:00 - 18:00.
(The entrance opens at 9:30 am)
Registration is required at the reception desk.
* Access information:
http://www.pioneer.co.jp/corp/profile/map/meguro/index-e.html
It will take 7 to 10 minutes by walk from Meguro station of JR
Yamanote-Line.
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 lohmeyer at t10.org  Tue May 16 10:30:41 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 16 May 2006 11:30:41 -0600
Subject: T10 Plenary minutes posted
Message-ID: <mailman.460.1441607308.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 May 11th have been posted at:
  http://www.t10.org/ftp/t10/document.06/06-233r0.htm
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Tue May 16 12:08:25 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 16 May 2006 13:08:25 -0600
Subject: SAS-2 Zoning Management Teleconference
Message-ID: <mailman.461.1441607308.22510.t10@sandbox.t10.org>

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

SAS-2 Zoning Management Teleconference
Date: Wednesday, May 17, 2006 
Time: 1:00 pm, Mountain Daylight Time (12:00 noon PDT, 2:00 pm CDT, 3:00 pm
EDT)
Duration: 2 hours
Audio Information:
Toll-free: 1-800-531-5745 or Direct: 1-719-955-2349
Passcode: 719-533-7560
Webex Information:
Topic: SAS Zoning Management Teleconference 
Meeting number: 571 398 332 
Meeting password: sas2config 
Please click the following link to see more information, or to join the
meeting. 
NEW USER? Prepare your computer in advance of the meeting by clicking New
User on the navigation bar. 
<https://lsilogic.webex.com/lsilogic/j.php?ED=89376077&UID=44542252> 
--
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 Elliott at hp.com  Tue May 16 18:17:16 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Tue, 16 May 2006 20:17:16 -0500
Subject: SAS-2 revision 4 and SES-2 revision 15 now available
Message-ID: <mailman.462.1441607308.22510.t10@sandbox.t10.org>

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

These working drafts:
- Serial Attached SCSI - 2 (SAS-2) revision 4 (sas2r04) 
- SCSI Enclosure Services - 2 (SES-2) revision 15 (ses2r15)
are now available on http://www.t10.org/drafts.htm and
http://www.t10.org/new.htm, incorporating proposals accepted at the May T10
plenary.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


From roweber at IEEE.org  Wed May 17 10:20:30 2006
From: roweber at IEEE.org (Ralph Weber)
Date: Wed, 17 May 2006 12:20:30 -0500
Subject: Additional Sense Codes updated
Message-ID: <mailman.463.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
I have updated the additional sense code assignments based on
the proposals approved by the May T10 meeting.
If you have an additional sense code assignment pending, please
review the online list for correctness.
http://www.t10.org/lists/asc-num.txt
Please report problems to me, thanks.
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Elliott at hp.com  Wed May 17 11:35:55 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 17 May 2006 13:35:55 -0500
Subject: Why do we need SMP initiators in the Expander Devices?
Message-ID: <mailman.464.1441607308.22510.t10@sandbox.t10.org>

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

Self-configuring expander devices use SMP initiator ports to perform the
discover process to fill in their own routing tables.  This is optional
behavior in SAS-1.1.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Dinesh C
> Sent: Wednesday, April 26, 2006 5:27 AM
> To: t10 at t10.org
> Subject: Why do we need SMP initiators in the Expander Devices?
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Dinesh C <cdinesh at perfectus.com>
> *
> Hello,
> Can any one explain ,why do we need an SMP initiatior in the Expander
> Device?.(are they used to connect another exander with it?)Is it
> possible to connect another Expander device with an exander device
> without an SMP initiator?
> 
> Regards
> Dinesh.C
> Design Engineer
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 


From Elliott at hp.com  Wed May 17 11:34:03 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 17 May 2006 13:34:03 -0500
Subject: 05-322r3 SAS-2 Wide port simultaneous connection rules
Message-ID: <mailman.465.1441607308.22510.t10@sandbox.t10.org>

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

As discussed in the SAS protocol WG last week, the next revision will change
that text to something more generic like "A port using this physical link
should not...".  That text is just describing the specific restriction
caused by the width of that physical link, not the combined restrictions
|from all the wide links from Port Z to port D.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf 
> Of Robert Kembel
> Sent: Wednesday, May 10, 2006 10:19 AM
> To: T10 Reflector
> Subject: 05-322r3 SAS-2 Wide port simultaneous connection rules
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Robert Kembel" <rwkembel at nlabooks.com>
> *
> Hi All,
> 
> In reading through this discussion, I had a question about 
> Figure 2. In the
> figure, it states:
> 
>  
> 
> "h) Port Z should not attempt to open more than 4 connections 
> to port D"
> 
>  
> 
> Shouldn't this say 1 connection based on the single link 
> between expander W
> and Y?
> 
>  
> 
>  
> 
> Bob
> 
>  
> 
> Robert W. Kembel
> Northwest Learning Associates, Inc.
> 13 Magnolia Circle
> White River Junction, VT  05001
> 802-295-5647, FAX: 802-295-5649
> 
> Visit our web site at  <http://www.nlabooks.com/&gt; www.NLAbooks.com
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 


From David.Peterson at mcdata.com  Wed May 17 17:15:15 2006
From: David.Peterson at mcdata.com (David Peterson)
Date: Wed, 17 May 2006 19:15:15 -0500
Subject: SSC-3: Conference Call on May 31st
Message-ID: <mailman.466.1441607308.22510.t10@sandbox.t10.org>

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

Howdy,
There will be an SSC-3 conference call on Wednesday May 31st from
10:00am to Noon Central time.
Focus will be on the Security related proposals (06-103 and 06-225).
Please send me a request for time for other items.
Call details:
Dial-in number: 1-800-653-7492
International Dial-in number: 1-770-325-4745
Conference ID: 5478097
Thanks...Dave
(no disclaimer)


From robert.l.sheffield at intel.com  Thu May 18 08:22:58 2006
From: robert.l.sheffield at intel.com (Sheffield, Robert L)
Date: Thu, 18 May 2006 08:22:58 -0700
Subject: SAT LB Teleconference TODAY noon PDT
Message-ID: <mailman.467.1441607308.22510.t10@sandbox.t10.org>

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

SAT LB Comment Resolution Teleconference (TODAY)
Webex information
URL: https://intel.webex.com/intel 
Meeting number: 826 557 998 
Password: Scsi2Ata!
Phone Bridge:
Phone: 1-916-356-2663
Bridge#: 1
Passcode: 1445849 


From lohmeyer at t10.org  Thu May 18 09:29:00 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 18 May 2006 10:29:00 -0600
Subject: SAS-2 Zoning Management Teleconference May 24
Message-ID: <mailman.468.1441607308.22510.t10@sandbox.t10.org>

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

SAS-2 Zoning Management Teleconference
Date: Wednesday, May 24, 2006 
Time: 1:00 pm, Mountain Daylight Time (12:00 noon PDT, 2:00 pm CDT, 3:00 pm
EDT)
Duration: 2 hours
Audio Information:
Toll-free: 1-800-531-5745 or Direct: 1-719-955-2349
Passcode: 719-533-7560
Webex Information:
Topic: SAS Zoning Management Teleconference 
Meeting number: 577 218 504 
Meeting password: sas2config 
Please click the following link to see more information, or to join the
meeting. 
NEW USER? Prepare your computer in advance of the meeting by clicking New
User on the navigation bar. 
<https://lsilogic.webex.com/lsilogic/j.php?ED=89412512&UID=44649517>
--
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 lohmeyer at t10.org  Thu May 18 09:29:07 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 18 May 2006 10:29:07 -0600
Subject: SAS-2 Zoning Management Teleconference May 31
Message-ID: <mailman.469.1441607308.22510.t10@sandbox.t10.org>

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

SAS-2 Zoning Management Teleconference
Date: Wednesday, May 31, 2006 
Time: 1:00 pm, Mountain Daylight Time (12:00 noon PDT, 2:00 pm CDT, 3:00 pm
EDT)
Duration: 2 hours
Audio Information:
Toll-free: 1-800-531-5745 or Direct: 1-719-955-2349
Passcode: 719-533-7560
Webex Information:
Topic: SAS Zoning Management Teleconference 
Meeting number: 571 081 167 
Meeting password: sas2config 
Please click the following link to see more information, or to join the
meeting. 
NEW USER? Prepare your computer in advance of the meeting by clicking New
User on the navigation bar. 
<https://lsilogic.webex.com/lsilogic/j.php?ED=89412582&UID=44649737> 
--
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 lohmeyer at t10.org  Thu May 18 14:52:08 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Thu, 18 May 2006 15:52:08 -0600
Subject: T10 Reflector clean up
Message-ID: <mailman.470.1441607308.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:
  sanjayg at ivivity.com
  greg.casey at qlogic.com
  Paul.A.Suhler at certance.com
  Dennis.W.Painter at certance.com
  Peter.S.Lim at certance.com
  Jim.Q.Wong at certance.com
  Gunter.T.Knestele at certance.com
  My.T.Pham at certance.com
  Doug.C.Pirie at certance.com
  Zung.X.Nguyen at certance.com
  kin-soon_liew at agilent.com
  chang-feng_loi at agilent.com
  mchenery at fcpa.fujitsu.com
  a-yamazaki at dc.jp.nec.com
  BH_Ng at adaptec.com
  fuxing_luo2004 at yahoo.ca
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
--
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 robert.l.sheffield at intel.com  Thu May 18 16:17:18 2006
From: robert.l.sheffield at intel.com (Sheffield, Robert L)
Date: Thu, 18 May 2006 16:17:18 -0700
Subject: T10 SCSI / ATA Translation LB Comment Resolution Meeting Announcement June 7,8 in Chandler, AZ
Message-ID: <mailman.471.1441607308.22510.t10@sandbox.t10.org>

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

SCSI / ATA Translation (SAT)
Meeting Announcement
T10 Technical Committee SAT WG
June 7, 8 2006 - Wed 9:00 AM - 7:00 PM and Thr 8:00 AM - noon
See announcement at: http://www.t10.org/ftp/t10/sat-ann.pdf
Hosted by: Intel Corporation
Location: Park Plaza Hotel
7475 W. Chandler Blvd.
Chandler, AZ 85226
http://www.parkplaza.com/chandleraz
33?18'15.2"N, 111?58'12.3"W
Reservations: @Park Plaza : (800) 814-7000 (no room block)
Parking: Free
Dining: Good hotel caf?, a few nearby, many 1-mi N on Ray Rd.
Group Name / room rate: N/A - No room block (see list of local hotels
attached)
Cutoff Date: N/A (no room block)
Directions from Phoenix Sky Harbor Airport:
Find I-10 (direction depends on which car rental you use, but it's close by).
Go East on I-10 towards Tucson for about 12 miles.
Take exit 160 to Chandler Blvd.
Turn left on Chandler Blvd. go 0.2 mi
Take immediate right on S. Southgate Drive
Take immediate right at round-about to enter hotel parking lot.
Arrive at 7475 W. Chandler Blvd., Chandler, AZ 85226


From daviburg at windows.microsoft.com  Fri May 19 12:43:55 2006
From: daviburg at windows.microsoft.com (David Burg)
Date: Fri, 19 May 2006 12:43:55 -0700
Subject: MMC: Merge DVD's disc structure 09h and BD's disc structure 09h
Message-ID: <mailman.472.1441607308.22510.t10@sandbox.t10.org>

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

Hello,
In mmc5r03, there are (Table 409) READ DISC STRUCTURE Data Format
(Format = 09h) and (Table 448) BD Format Structure Code 09h: Cartridge
Status. Yet BD's structure is only repeating the table 409 structure
while reserving fields other than Cartridge, OUT and CWP.
I suggest that format code 09h is moved to the generic disc structures
and that fields other than Cartridge, OUT and CWP are just marked as
reserved for BD.
Best regards,
David Burg
Research Software Engineering Lead
Tel.: +1 425 707 8769


From lohmeyer at t10.org  Fri May 19 14:09:27 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Fri, 19 May 2006 15:09:27 -0600
Subject: John Scheible
Message-ID: <mailman.473.1441607308.22510.t10@sandbox.t10.org>

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

It is with great sadness that I am informing you that John Scheible died on
Monday May 15th. Services were held earlier this week. He is survived by his
wife, Peg, and three  sons (11, 13, and 15).
The long-time members of T10 will remember that John chaired T10.1, a task
group of T10 that developed the SSA family of standards. John was also quite
active on various Fibre Channel projects. John worked for IBM in Austin, TX. 
I know that John would want me to include this paragraph from his June 2004
email announcing his illness:
>Public service announcement.  Remember the colonoscopy guys!.	I had no
history and should not have had my first for two more years (50).  However,
8% of colon cancer occurs before the age of 50.  I had almost no symptoms.
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907


From lohmeyer at t10.org  Sat May 20 23:00:47 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 21 May 2006 00:00:47 -0600
Subject: Recent T10 documents uploaded since 2006/05/14
Message-ID: <mailman.474.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
ISO/IEC SCSI Part Number Score Card
(by: Ralph O. Weber)
T10/05-071r4   Uploaded: 2006/05/15   23765 bytes
ftp://ftp.t10.org/t10/document.05/05-071r4.pdf
SAS-2 Configuring bit
(by: Tim Symons)
T10/06-097r4   Uploaded: 2006/05/15   32813 bytes
ftp://ftp.t10.org/t10/document.06/06-097r4.pdf
SAS-2 Self-configuring expander device model
(by: Tim Symons)
T10/06-098r5   Uploaded: 2006/05/15   140140 bytes
ftp://ftp.t10.org/t10/document.06/06-098r5.pdf
SAM-3: Converting to UML part 1
(by: George O. Penokie)
T10/06-116r2   Uploaded: 2006/05/19   460645 bytes
ftp://ftp.t10.org/t10/document.06/06-116r2.pdf
SAS-2 BREAK_REPLY
(by: Tim Hoglund)
T10/06-119r2   Uploaded: 2006/05/14   325561 bytes
ftp://ftp.t10.org/t10/document.06/06-119r2.pdf
SAS-2 Require expanders transmit three AIPs
(by: Rob Elliott)
T10/06-164r2   Uploaded: 2006/05/14   35671 bytes
ftp://ftp.t10.org/t10/document.06/06-164r2.pdf
ADC-2: Device Statistics log page parameter updates
(by: Kevin Marks)
T10/06-183r1   Uploaded: 2006/05/16   31661 bytes
ftp://ftp.t10.org/t10/document.06/06-183r1.pdf
SSC-3: Using NIST AES Key-Wrap for Key Establishment
(by: Matt Ball)
T10/06-225r1   Uploaded: 2006/05/18   51494 bytes
ftp://ftp.t10.org/t10/document.06/06-225r1.pdf
Minutes of CAP Working Group - May 10, 2006
(by: Weber & Lohmeyer)
T10/06-232r0   Uploaded: 2006/05/15   22409 bytes
ftp://ftp.t10.org/t10/document.06/06-232r0.htm
Minutes of CAP Working Group - May 10, 2006
(by: Weber & Lohmeyer)
T10/06-232r0   Uploaded: 2006/05/15   92412 bytes
ftp://ftp.t10.org/t10/document.06/06-232r0.pdf
Minutes of T10 Plenary Meeting #73 - May 11, 2006
(by: Weber & Lohmeyer)
T10/06-233r0   Uploaded: 2006/05/16   82762 bytes
ftp://ftp.t10.org/t10/document.06/06-233r0.htm
Minutes of T10 Plenary Meeting #73 - May 11, 2006
(by: Weber & Lohmeyer)
T10/06-233r0   Uploaded: 2006/05/16   280304 bytes
ftp://ftp.t10.org/t10/document.06/06-233r0.pdf
SSC-3: Working Group Agenda - May 9, 2006
(by: David Peterson)
T10/06-241r0   Uploaded: 2006/05/15   9782 bytes
ftp://ftp.t10.org/t10/document.06/06-241r0.pdf
Agenda for T10 Meeting #74 (July 2006)
(by: John Lohmeyer)
T10/06-254r0   Uploaded: 2006/05/15   53613 bytes
ftp://ftp.t10.org/t10/document.06/06-254r0.pdf
T10 Project Summary - May 2006
(by: John Lohmeyer)
T10/06-255r0   Uploaded: 2006/05/15   34823 bytes
ftp://ftp.t10.org/t10/document.06/06-255r0.pdf
Jeopardy Letter for July 2006 meeting
(by: John Lohmeyer)
T10/06-256r0   Uploaded: 2006/05/15   88570 bytes
ftp://ftp.t10.org/t10/document.06/06-256r0.pdf
BERTScope ISI Board
(by: Harvey Newman)
T10/06-258r0   Uploaded: 2006/05/17   2052811 bytes
ftp://ftp.t10.org/t10/document.06/06-258r0.pdf
SAM-4, et al.: making linked commands obsolete
(by: Mark Evans)
T10/06-259r0   Uploaded: 2006/05/17   130962 bytes
ftp://ftp.t10.org/t10/document.06/06-259r0.pdf
Working Drafts
--------------
Automation/Drive Interface - Commands - 2 (ADC-2)
(Editor: Paul Entzel)
 Rev: 05       Uploaded: 2006/05/15   473716 bytes
ftp://ftp.t10.org/t10/drafts/adc2/adc2r05.pdf
Automation/Drive Interface - Transport Protocol - 2 ADT-2)
(Editor: Suhler / Entzel)
 Rev: 02       Uploaded: 2006/05/16   1057556 bytes
ftp://ftp.t10.org/t10/drafts/adt2/adt2r02.pdf
Serial Attached SCSI - 2 (SAS-2)
(Editor: Rob Elliott)
 Rev: 04       Uploaded: 2006/05/16   5965447 bytes
ftp://ftp.t10.org/t10/drafts/sas2/sas2r04.pdf
(Report generated on 2006/05/21 at 00:00:46)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From michael.banther at hp.com  Mon May 22 08:10:55 2006
From: michael.banther at hp.com (Banther, Michael)
Date: Mon, 22 May 2006 16:10:55 +0100
Subject: T10 SMC-3 Working Group teleconference
Message-ID: <mailman.475.1441607308.22510.t10@sandbox.t10.org>

Formatted message: <A HREF="r0605220_f.htm">HTML-formatted message</A>
Attachment #1: <A HREF="r0605220_banthermichae.vcf">banthermichae.vcf</A>

The SMC-3 working group will hold a teleconference on Monday, 5 June
2006 starting at 8:00 AM PDT and concluding at 10:00 AM PDT.  Contact
details and an agenda will follow at a time closer to the
teleconference.
Regards,
Michael Banther
Hewlett-Packard Ltd.
Telephone +44 (117) 312-9503


From victor.lau at intel.com  Tue May 23 06:16:01 2006
From: victor.lau at intel.com (Lau, Victor)
Date: Tue, 23 May 2006 09:16:01 -0400
Subject: Question for phy event counters 
Message-ID: <mailman.476.1441607308.22510.t10@sandbox.t10.org>

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

In sas2r04 spec page 103, it states the following events should use the
saturating counters
Phys shall count the following events using saturating counters and
report them in the Protocol-Specific Port
log page (see 10.2.8.1) and/or the SMP REPORT PHY ERROR LOG function
(see 10.4.3.6):
a) invalid dwords received;
b) dwords received with running disparity errors;
c) loss of dword synchronization; and
d) phy reset problems.
However, on p.104, table 24, these 4-events are using counter type
"wrapping counter"
Thus, which type of counter we should use?
Thx
Victor


From halvard.eriksen at tandberg.com  Tue May 23 07:10:23 2006
From: halvard.eriksen at tandberg.com (Halvard Eriksen)
Date: Tue, 23 May 2006 16:10:23 +0200
Subject: ADI: The functionallity of the Offline bit in ModePage 0Eh, Subpage 03h The RMC logical unit descriptor.
Message-ID: <mailman.477.1441607308.22510.t10@sandbox.t10.org>

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

To the members of the ADI working group.
In the RMC Logical Unit Descriptor in Modepage 0Eh, Sunpage 03h, the
description of the Offline bit states that
if this bit is set to one, the RMC device server shall respond with a
Check Condition to all SCSI commands.
The Sk/Asc/Ascq shall be 02h/04h/12h Logical Unit Not Ready, Offline.
This Asc/Ascq is specified in SPC-4 to apply to Media Change Devices and
to the Automation/Drive interface
and not to the Sequential Access Devices.
Is the tape drive in an Aotomation device considered to be a part of the
Media Changer Device from the SPC-4 point of view?.
If not, should someone have SPC-4 add the Sequential access device to
the list of devices implementing this ASCQ?
Regards
Halvard Eriksen
Tandberg Data


From Elliott at hp.com  Tue May 23 07:50:33 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Tue, 23 May 2006 09:50:33 -0500
Subject: Question for phy event counters 
Message-ID: <mailman.478.1441607308.22510.t10@sandbox.t10.org>

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

The original REPORT PHY ERROR LOG has four saturating counters for those
events.  These are mandatory.
The new REPORT PHY EVENT INFORMATION has four wrapping counters for those
same events.  These are optional.  Wrapping counters are easier for
multi-initiator systems to track.
-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
https://ecardfile.com/id/RobElliott 
  _____  
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Lau, Victor
Sent: Tuesday, May 23, 2006 8:16 AM
To: t10 at t10.org
Cc: Lau, Victor; Seto, Pak-lung
Subject: Question for phy event counters 
In sas2r04 spec page 103, it states the following events should use the
saturating counters
Phys shall count the following events using saturating counters and report
them in the Protocol-Specific Port
log page (see 10.2.8.1) and/or the SMP REPORT PHY ERROR LOG function (see
10.4.3.6):
a) invalid dwords received;
b) dwords received with running disparity errors;
c) loss of dword synchronization; and
d) phy reset problems.
However, on p.104, table 24, these 4-events are using counter type "wrapping
counter"
Thus, which type of counter we should use?
Thx
Victor


From robert.l.sheffield at intel.com  Tue May 23 09:19:47 2006
From: robert.l.sheffield at intel.com (Sheffield, Robert L)
Date: Tue, 23 May 2006 09:19:47 -0700
Subject: SAT June 7,8 in Phoenix (RSVP Please)
Message-ID: <mailman.479.1441607308.22510.t10@sandbox.t10.org>

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

Hi all,
I have reserved a conference room in the Park Plaza Hotel June 7 and 8
for a face-to-face SCSI/ATA Translation working group meeting to work
through the last of the SAT letter-ballot comments (see announcement:
http://www.t10.org/ftp/t10/sat-ann.pdf).
By word of mouth, however, it's starting to look like the meeting may
not be very well attended. I have had several regular participants tell
me they do not intend to attend, and others have said they don't want to
incur the travel expense unless some of the key attendees are there to
help resolve the 90 or so LB comments that remain.
So, please RSVP and let me know if you plan on attending. I will use the
RSVP replies to determine whether it is worth holding the meeting or
not. I understand there are a handful of you who already have your plane
tickets booked, but if it's not going to be a productive meeting, I have
trouble justifying Intel's expense to host the meeting.
I really would like to use this June meeting to come as close as
possible to resolving the last of the LB comments so we can ask for a
vote to forward to INCITS in July and move forward with SAT-2.
Please RSVP to the reflector, or to my e-mail (on the T10 website).
Best regards,
Bob Sheffield (your humble SAT edtior)


From kdbutt at us.ibm.com  Tue May 23 10:07:32 2006
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 23 May 2006 10:07:32 -0700
Subject: ADI: The functionality of the Offline bit in ModePage 0Eh, Subpage 03h
 The RMC logical unit descriptor.
Message-ID: <mailman.480.1441607308.22510.t10@sandbox.t10.org>

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

Halvard,
Yes this ASCQ should be added to the Sequential Access Device column in 
SPC-4.
Ralph,
Can you do this editorially?
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/ 
"Halvard Eriksen" <halvard.eriksen at tandberg.com> 
Sent by: owner-t10 at t10.org
05/23/2006 07:10 AM
To
<t10 at t10.org>
cc
Subject
ADI: The functionallity of the Offline bit in ModePage 0Eh, Subpage 03h 
The RMC logical unit descriptor.
To the members of the ADI working group.
In the RMC Logical Unit Descriptor in Modepage 0Eh, Sunpage 03h, the 
description of the Offline bit states that
if this bit is set to one, the RMC device server shall respond with a 
Check Condition to all SCSI commands.
The Sk/Asc/Ascq shall be 02h/04h/12h Logical Unit Not Ready, Offline.
This Asc/Ascq is specified in SPC-4 to apply to Media Change Devices and 
to the Automation/Drive interface
and not to the Sequential Access Devices.
Is the tape drive in an Aotomation device considered to be a part of the 
Media Changer Device from the SPC-4 point of view?.
If not, should someone have SPC-4 add the Sequential access device to the 
list of devices implementing this ASCQ?
Regards
Halvard Eriksen
Tandberg Data


From steve.finch at st.com  Tue May 23 14:14:37 2006
From: steve.finch at st.com (Stephen FINCH)
Date: Tue, 23 May 2006 15:14:37 -0600
Subject: SAS-2 Bus Inactivity Timer
Message-ID: <mailman.481.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
When going from SAS 1.1 to SAS 2 and incorporating changes contained per
05-305r0, we accidentally broke the Bus Inactivity Timer.
In section 8.2.3.4.1 PL_PM3:Connected state description, it states:
???If:
    a) the protocol for the connection is SSP, the port is an SSP target
port, and the BUS INACTIVITY TIME LIMIT
       field in the Disconnect-Reconnect mode page (see 10.2.7.1) is set to a
non-zero value; or
    b) the protocol for the connection is STP, the port is an STP initiator
port, and the STP BUS INACTIVITY TIME
       LIMIT field is not set to zero in the SMP REPORT GENERAL response for
the destination STP target
       port,
then, upon entry into this state, this state shall:
    a) create a Bus Inactivity Time Limit timer;
    b) initialize the Bus Inactivity Time Limit timer as specified in table
122 (see 8.2.3.1); and
    c) start the Bus Inactivity Time Limit timer.
If a Bus Inactivity Time Limit timer has been created and:
    a) the connection is SSP or SMP and this state receives a Tx Frame
message; or 
    b) the connection is STP and the phy is not both transmitting and
receiving SATA_SYNC,
then this state shall:
    a) stop the Bus Inactivity Time Limit timer, if it is running; and
    b) initialize the Bus Inactivity Time Limit timer as specified in table
122 (see 8.2.3.1).???
My interpretation is the timer to be created when the connection is
established.
When the transport requests a frame to be transmitted, the timer is stopped.
There is no case that it is again started.  Thus no timeout will occur.  This
is WRONG.
Proposed solution:
Add a third step to the actions to be taken after receiving a Tx Frame
message so that the 
second ???if??? quoted above reads as follows:
???If a Bus Inactivity Time Limit timer has been created and:
    a) the connection is SSP or SMP and this state receives a Tx Frame
message; or 
    b) the connection is STP and the phy is not both transmitting and
receiving SATA_SYNC,
then this state shall:
    a) stop the Bus Inactivity Time Limit timer, if it is running; and
    b) initialize the Bus Inactivity Time Limit timer as specified in table
122 (see 8.2.3.1).
    c) start the Bus Inactivity Time Limit timer.???
Regards,
Stephen 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 gop at us.ibm.com  Tue May 23 14:53:10 2006
From: gop at us.ibm.com (George Penokie)
Date: Tue, 23 May 2006 16:53:10 -0500
Subject: Fw: T10 Working Draft Assignment: sam4r06
Message-ID: <mailman.482.1441607308.22510.t10@sandbox.t10.org>

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

A new version of SAM-4 has been posted that contains the conversion to 
UML.
2006/05/23 15:48:53 
Your request to upload a file or files to the T10 site has been accepted.
Your file will be posted at:
   http://www.t10.org/ftp/t10/drafts/sam4/sam4r06.pdf


From steve.finch at st.com  Wed May 24 11:56:56 2006
From: steve.finch at st.com (Stephen FINCH)
Date: Wed, 24 May 2006 12:56:56 -0600
Subject: SAS-2 Bus Inactivity Timer
Message-ID: <mailman.483.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
Gerry,
I think that the step before the added step reinitializes the Bus Inactivity
Timer.	So starting it after it was initialized should be right. This timer
is to make sure this device doesn???t tie up the bus, thus it monitors only
the transmit activity.	The other end of the bus should be monitoring itself.
As to the timer running while a frame is being sent, you are right. This
change would start the time upon the receipt of a frame request.  It
doesn???t account for the time delays due to credit not being available, the
transmission time of the frame itself or the delay in receiving back an ACK
or NAK. 
In SAS 1.1, the timer was stopped when a frame transmit request was received
|from the PL_OC state machine, and reset and restarted when an ACK or NAK was
received. If an ACK or NAK was not received, the ACK/NAK timeout would catch
it.  This, to me, is a better solution.
This area was removed in the update caused by the 05-305 document and appears
for the first time in SAS-2r00.
I think this discussion will be helpful to other.  Can I send it to the
reflector?
Additional comments/questions requested.
Steve Finch
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com] 
Sent: Wednesday, May 24, 2006 7:32 AM
To: steve.finch at st.com
Subject: Re: SAS-2 Bus Inactivity Timer
In the step you added:
"(c) start the Bus Inactivity Time Limit timer."
Shouldn't the timer be set to zero before it is started? Also, shouldn't
there be a wait until the "bus is inactive again" before the timer is
started? Per the change you propose, it seems like the timer will be started
again while a frame is being received or sent. This shouldn't count as an
inactive bus.
	     Stephen FINCH						   
	     <steve.finch at st.c						   
	     om>							To 
	     Sent by:		       <t10 at t10.org>			   
	     owner-t10 at t10.org						cc 
	     No Phone Info						   
	     Available						   Subject 
				       SAS-2 Bus Inactivity Timer	   
	     05/23/2006 04:14						   
	     PM 							   
* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen FINCH <steve.finch at st.com>
*
When going from SAS 1.1 to SAS 2 and incorporating changes contained per
05-305r0, we accidentally broke the Bus Inactivity Timer.
In section 8.2.3.4.1 PL_PM3:Connected state description, it states:
???If:
    a) the protocol for the connection is SSP, the port is an SSP target
port, and the BUS INACTIVITY TIME LIMIT
       field in the Disconnect-Reconnect mode page (see 10.2.7.1) is set to a
non-zero value; or
    b) the protocol for the connection is STP, the port is an STP initiator
port, and the STP BUS INACTIVITY TIME
       LIMIT field is not set to zero in the SMP REPORT GENERAL response for
the destination STP target
       port,
then, upon entry into this state, this state shall:
    a) create a Bus Inactivity Time Limit timer;
    b) initialize the Bus Inactivity Time Limit timer as specified in table
122 (see 8.2.3.1); and
    c) start the Bus Inactivity Time Limit timer.
If a Bus Inactivity Time Limit timer has been created and:
    a) the connection is SSP or SMP and this state receives a Tx Frame
message; or
    b) the connection is STP and the phy is not both transmitting and
receiving SATA_SYNC,
then this state shall:
    a) stop the Bus Inactivity Time Limit timer, if it is running; and
    b) initialize the Bus Inactivity Time Limit timer as specified in table
122 (see 8.2.3.1).???
My interpretation is the timer to be created when the connection is
established. When the transport requests a frame to be transmitted, the timer
is stopped. There is no case that it is again started.	Thus no timeout will
occur. This is WRONG.
Proposed solution:
Add a third step to the actions to be taken after receiving a Tx Frame
message so that the second ???if??? quoted above reads as follows:
???If a Bus Inactivity Time Limit timer has been created and:
    a) the connection is SSP or SMP and this state receives a Tx Frame
message; or
    b) the connection is STP and the phy is not both transmitting and
receiving SATA_SYNC,
then this state shall:
    a) stop the Bus Inactivity Time Limit timer, if it is running; and
    b) initialize the Bus Inactivity Time Limit timer as specified in table
122 (see 8.2.3.1).
    c) start the Bus Inactivity Time Limit timer.???
Regards,
Stephen 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 lohmeyer at t10.org  Fri May 26 08:13:07 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Fri, 26 May 2006 09:13:07 -0600
Subject: Meeting Notice: SAS-2 Config Mgmt WG June 20 Denver
Message-ID: <mailman.484.1441607308.22510.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
Meeting Notice: SAS-2 Configuration Management Working Group
Date:		Tuesday, June 20, 2006
Time:		9:30 am - 4:00 pm
Location:	Courtyard Denver Airport
		6901 Tower Rd.
		Denver, CO 80249
       Phone:	1-303-371-0300
	 Fax:	1-303-371-2480
	 URL:	http://marriott.com/property/propertypage/DENAP
There is complimentary shuttle service to/from the airport (use the courtesy
phones in baggage claim). If you are driving, the hotel URL has a map and
driving directions.
John
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Logic Corp. 	       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From lohmeyer at t10.org  Sat May 27 23:00:46 2006
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 28 May 2006 00:00:46 -0600
Subject: Recent T10 documents uploaded since 2006/05/21
Message-ID: <mailman.485.1441607308.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 Wide port simultaneous connection recommendations
(by: Rob Elliott)
T10/05-322r4   Uploaded: 2006/05/22   55265 bytes
ftp://ftp.t10.org/t10/document.05/05-322r4.pdf
SAS-2 SMP Lists (DISCOVER LIST)
(by: Steve Johnson)
T10/06-037r6   Uploaded: 2006/05/26   118920 bytes
ftp://ftp.t10.org/t10/document.06/06-037r6.pdf
SAS-2 Expander Routing Table (REPORT EXPANDER ROUTE TABLE)
(by: Steve Johnson)
T10/06-078r2   Uploaded: 2006/05/26   90251 bytes
ftp://ftp.t10.org/t10/document.06/06-078r2.pdf
SAM-3: Converting to UML part 1
(by: George O. Penokie)
T10/06-116r3   Uploaded: 2006/05/22   462043 bytes
ftp://ftp.t10.org/t10/document.06/06-116r3.pdf
SAS-2 REPORT GENERAL additions for zoning and self configuration
(by: Steve Johnson)
T10/06-213r1   Uploaded: 2006/05/26   70566 bytes
ftp://ftp.t10.org/t10/document.06/06-213r1.pdf
SAS-2 zone management use cases
(by: Rob Elliott)
T10/06-260r0   Uploaded: 2006/05/24   45501 bytes
ftp://ftp.t10.org/t10/document.06/06-260r0.pdf
Working Drafts
--------------
Automation/Drive Interface - Commands - 2 (ADC-2)
(Editor: Paul Entzel)
 Rev: 05a      Uploaded: 2006/05/26   730266 bytes
ftp://ftp.t10.org/t10/drafts/adc2/adc2r05a.pdf
SCSI Architecture Model - 4 (SAM-4)
(Editor: George Penokie)
 Rev: 06       Uploaded: 2006/05/23   1188483 bytes
ftp://ftp.t10.org/t10/drafts/sam4/sam4r06.pdf
(Report generated on 2006/05/28 at 00:00:45)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Elliott at hp.com  Tue May 30 09:10:54 2006
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Tue, 30 May 2006 11:10:54 -0500
Subject: SAS-2 Zoning Management Teleconference May 31 CHANGE TO June 2 
Message-ID: <mailman.486.1441607308.22510.t10@sandbox.t10.org>

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

This teleconference has been rescheduled for Friday 2 June 2006, still at
12pm/1pm/2pm/3pm Pacific/Mountain/Central/Eastern time.
Telephone:  866-639-4721 or 574-948-0372
Participant code: 5185037
We'll be using HP's Virtual Rooms software rather than WebEx.  Use the
following link before the meeting to install the software:
    https://www.rooms.hp.com/testsetup 
Participant access:
  https://www.rooms.hp.com/attend/default.aspx?key=EPVFWUJJRH 
-- 
Rob Elliott, elliott at hp.com 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 
https://ecardfile.com/id/RobElliott 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of John
Lohmeyer
	Sent: Thursday, May 18, 2006 11:29 AM
	To: T10 Reflector
	Subject: SAS-2 Zoning Management Teleconference May 31
	SAS-2 Zoning Management Teleconference
	Date: Wednesday, May 31, 2006 
	Time: 1:00 pm, Mountain Daylight Time (12:00 noon PDT, 2:00 pm CDT,
3:00 pm EDT)
	Duration: 2 hours
	Audio Information:
	Toll-free: 1-800-531-5745 or Direct: 1-719-955-2349
	Passcode: 719-533-7560
	Webex Information:
	Topic: SAS Zoning Management Teleconference 
	Meeting number: 571 081 167 
	Meeting password: sas2config 
	Please click the following link to see more information, or to join
the meeting. 
	NEW USER? Prepare your computer in advance of the meeting by
clicking New User on the navigation bar. 
	<https://lsilogic.webex.com/lsilogic/j.php?ED=89412582&UID=44649737>
	--
	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 Alvin.Cox at seagate.com  Tue May 30 10:41:01 2006
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Tue, 30 May 2006 12:41:01 -0500
Subject: Reminder: SAS PHY working group teleconference, Thursday, June 1 @ 10 am
 CDT
Message-ID: <mailman.487.1441607308.22510.t10@sandbox.t10.org>

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

Agenda:
Training sequence/speed negotiation
Spread Spectrum Clocking
Specification of transmitter device equalization (TCTF, system 
intellignece?)
Secondary port connector electrical characterization
New items
Bi-weekly conference calls starting June 1, 2006
PARTICIPANT INFORMATION: 
All Participants should use the following information to reach the 
conference calls: 
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: Bi-weekly starting Thursday, June 1, 2006 
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS
Alvin Cox
Seagate Technology, LLC
Tel 405-350-7424
Cell 405-206-4809


From robert.l.sheffield at intel.com  Wed May 31 08:04:23 2006
From: robert.l.sheffield at intel.com (Sheffield, Robert L)
Date: Wed, 31 May 2006 08:04:23 -0700
Subject: SAT - LB comment resolution face-to-face June 19, Santa Clara
Message-ID: <mailman.488.1441607308.22510.t10@sandbox.t10.org>

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

T10 committee,
In addition to the June 7,8 meeting in Chandler, AZ, there will be a
SCSI / ATA Translation (SAT) LB comment resolution meeting June 19 in
Santa Clara, CA.
The meeting will be from 9:00 AM until 6:00 PM.
This meeting is the day before the T13 meetings in the same location.
Where: NVIDIA Corporation 
	    2701 San Tomas Expressway 
	    Santa Clara, CA 95051 
Map:
http://maps.google.com/maps?f=q&hl=en&q=2701+san+tomas+expressway,+95051
&ll=37.371078,-121.965494&spn=0.025648,0.059052&om=1
The entrance is off of Walsh to building D. 
Please check in building D for a pass. The meetings are in building E. 
It's a short walk to the other side of the campus, or you can drive over
after 
checking in building D.
Regards,
Bob Sheffield


From robert.l.sheffield at intel.com  Wed May 31 10:15:17 2006
From: robert.l.sheffield at intel.com (Sheffield, Robert L)
Date: Wed, 31 May 2006 10:15:17 -0700
Subject: FW: [t13] FW: SAT - LB comment resolution face-to-face June 19, Santa Clara
Message-ID: <mailman.489.1441607308.22510.t10@sandbox.t10.org>

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

________________________________
From: Mark Overby [mailto:MOverby at nvidia.com] 
Sent: Wednesday, May 31, 2006 10:08 AM
To: Sheffield, Robert L; forum at t13.org
Subject: RE: [t13] FW: SAT - LB comment resolution face-to-face June 19,
Santa Clara
Ah, one note - the meeting on Monday will be in building D. Other than
that, it remains the same.
Please RSVP for Monday to myself (and Bob) as I need to get a headcount
to make sure I don't need a larger room.
________________________________
From: owner-forum at t13.org [mailto:owner-forum at t13.org] On Behalf Of
Sheffield, Robert L
Sent: Wednesday, May 31, 2006 8:06 AM
To: forum at t13.org
Subject: [t13] FW: SAT - LB comment resolution face-to-face June 19,
Santa Clara
Importance: High
T13 committee, 
In addition to the June 7,8 meeting in Chandler, AZ, there will be a
SCSI / ATA Translation (SAT) LB comment resolution meeting June 19 in
Santa Clara, CA.
The meeting will be from 9:00 AM until 6:00 PM.
This meeting is the day before the T13 meetings in the same location.
Where: NVIDIA Corporation 
	    2701 San Tomas Expressway 
	    Santa Clara, CA 95051 
Map:
http://maps.google.com/maps?f=q&hl=en&q=2701+san+tomas+expressway,+95051
&ll=37.371078,-121.965494&spn=0.025648,0.059052&om=1
The entrance is off of Walsh to building D. 
Please check in building D for a pass. The meetings are in building E. 
It's a short walk to the other side of the campus, or you can drive over
after 
checking in building D.
Regards,
Bob Sheffield
________________________________
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 support at terabyteunlimited.com  Wed May 31 15:52:20 2006
From: support at terabyteunlimited.com (David F.)
Date: Wed, 31 May 2006 15:52:20 -0700
Subject: Incremental Write on DVD+RW media?
Message-ID: <mailman.490.1441607308.22510.t10@sandbox.t10.org>

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

It be nice to have links on T10 somewhere on reporting problems to
manufacturer's of drives.
In any case, a Sony DRU 820A reports that Incremental Stream Writing feature
is available and current when a formatted or brand new unformatted DVD+RW
disc is in the drive.  I don't think that's correct, at least the way I read
the specs regarding the current bit. 
--
David F.
TeraByte Unlimited
http://www.terabyteunlimited.com
This email and any attachments are intended solely for the individual or
entity to which it is addressed.  If you have received this email in error,
please reply immediately to the sender that you have received the email in
error and permanently delete it.  If you are not the intended recipient, any
disclosure, copying, distribution, or use of the contents of this
information is prohibited.    


From lohmeyer at t10.org  Wed May 31 19:36:58 2006
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 31 May 2006 20:36:58 -0600
Subject: Incremental Write on DVD+RW media?
Message-ID: <mailman.491.1441607308.22510.t10@sandbox.t10.org>

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

David,
I know you mean well, but implementing such links and publicly posting
complaints about specific products may be dangerously close to violating
antitrust laws. I'd much rather that people who have issues with products
contact the manufacturer directly.
Regards,
John
At 5/31/2006 03:52 PM, David F. wrote:
>It be nice to have links on T10 somewhere on reporting problems to
manufacturer's of drives. 
>
>In any case, a Sony DRU 820A reports that Incremental Stream Writing feature
is available and current when a formatted or brand new unformatted DVD+RW
disc is in the drive.  I don't think that's correct, at least the way I read
the specs regarding the current bit. 
>
>
>
>-- 
>David F. 
>TeraByte Unlimited 
><http://www.terabyteunlimited.com">http://www.terabyteunlimited.com>http://www.terabyteunlimited.com 
>
>This email and any attachments are intended solely for the individual or
entity to which it is addressed.  If you have received this email in error,
please reply immediately to the sender that you have received the email in
error and permanently delete it.  If you are not the intended recipient, any
disclosure, copying, distribution, or use of the contents of this information
is prohibited.	  
--
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