From George.Penokie at lsi.com  Wed Apr  1 06:06:19 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Wed, 1 Apr 2009 07:06:19 -0600
Subject: 09-063r1  comment
Message-ID: <mailman.181.1441607348.22516.t10@sandbox.t10.org>

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

Craig,
That is an error in SAS-2 that will be fixed in revision 16 per the below
note that went out two weeks ago from Bill Martin.
Rob & T10:
At the SAS protocol meeting today, it was discovered that in the SP11 state
there is an error in 6.8.4.5.3.
In 6.7.2.3.2 where the protocol for speed negotiation windows is defined
there are the following two statements:
In Figure 154 it states -
If the phy's receiver achieves dword synchronization at the SNW rate within
SNLT, its transmitter transmits ALIGN (1)s at the SNW rate for the remainder
of the SNTT.
After table 99 it states -
If the phy supports the SNW, then after RCDT it shall attempt to attain dword
synchronization on an incoming series of dwords (e.g., ALIGN (0) or ALIGN (1)
primitives) at that rate for the SNLT:
a)			   if the phy achieves dword synchronization within
the SNLT, then it shall change from transmitting ALIGN (0) primitives to
transmitting ALIGN (1) primitives for the remainder of the SNTT (i.e., the
remainder of the SNW time). The point at which the phy achieves dword
synchronization is called the actual lock time (ALT); or
b)			   if the phy does not achieve dword synchronization
within the SNLT, then it shall continue transmitting ALIGN (0) primitives for
the remainder of the SNTT (i.e., the remainder of the SNW time).
At the end of the SNTT:
a)			   if the phy is both transmitting and receiving
ALIGN (1) primitives, then it shall consider the SNW to be valid; or
b)			   if the phy is not both transmitting and receiving
ALIGN (1) primitives, then it shall consider the SNW to be invalid. The phy
shall disable SSC (see 5.7.6) during SNW-1, SNW-2, and Final-SNW.
The first list is describing state SP10 and item a) is the transition from
SP10 to SP11.  The second list is describing SP11 and item a) is the
transition from SP11 to SP12.	The issue is that the transition from SP11 to
SP12 is taken "if phy is both transmitting and receiving ALIGN (1)
primitives" by the end of SNTT; however 6.8.4.5.3 states:
6.8.4.5.3 Transition SP11:SAS_AwaitALIGN1 to SP12:SAS_AwaitSNW
This transition shall occur if this state receives an ALIGN Received (1)
message before the SNLT timer expires. This indicates that the attached phy
has been able to achieve dword synchronization in the current SNW.
This transition is based on receiving the ALIGN Received (1) message before
the SNLT timer expires not the SNTT timer.  It was agreed by those present at
the SAS protocol working group meeting today that this should be changed to
SNTT in the version of SAS-2 that is published for public review.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
________________________________
From: Craig Stoops [mailto:craig at expertio.com]
Sent: Tuesday, March 31, 2009 7:31 PM
To: t10 at t10.org
Cc: Penokie, George
Subject: 09-063r1 comment
Hi George,
In your posting of 09-063r1 today,  section 5.6.5.3 has the timer changed
|from SNLT to SNTT from the original 2008 proposal.
Questions:
1) Is this in fact correct that the timer is changed
2) If so, there is still a reference to SNLT in 5.6.5.3.3 (a), I assume this
should also be SNTT.
    If SNLT in this section is correct, then SNLT is missing initialization
(starting) and any consequent actions on SNLT expiring in the PS states.
Secondly, regarding section 5.6.5.4.3 "footnote" of:
"Receipt of the ALIGN Received (1) message indicates that the connected phy
has been able to achieve dword synchronization with the previously negotiated
settings."
Questions:
1) Does this only apply to the 5.6.5.4.3 transition and not to the 5.6.5.3.3
transition to ALIGN1 state? Ie ALIGN0 state can transition to ALIGN
regardless of DWS sync?
   If so, I would like to suggest that maybe just 5.6.5.4.3 "a" should just
read:
    "a) If the DWS is synced, and this state receives an ALIGN Received (1)
message before the SNTT timer expires..."
    because other places in the phy spec the ALIGN Received message does not
imply the DWS is synced. I think it would be clearer and more consistent.
Please advise
Thanks,
Craig Stoops
ExpertIO, Inc. - "Your Storage Protocol Verification Experts"
www.expertio.com<<a href="http://www.expertio.com&gt">http://www.expertio.com&gt;


From George.Penokie at lsi.com  Wed Apr  1 08:37:52 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Wed, 1 Apr 2009 08:37:52 -0700
Subject: 09-063r1  comment (retry)
Message-ID: <mailman.182.1441607348.22516.t10@sandbox.t10.org>

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

Craig,
There was a transcribe error on my part. Item 1 in section 5.6.5.3.1 should
have been stated as
1)  initialize and start the SNTT timer and the SNLT timer;
The sentence in section 5.6.5.4.3 " Receipt of the ALIGN Received (1) message
indicates that the connected phy has been able to achieve dword
synchronization with the previously negotiated settings." does not belong in
a transition section and will be deleted from that section. It will either
move to another section or be removed pending a discussion at the next
working group.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
________________________________
From: Craig Stoops [mailto:craig at expertio.com]
Sent: Tuesday, March 31, 2009 7:31 PM
To: t10 at t10.org
Cc: Penokie, George
Subject: 09-063r1 comment
Hi George,
In your posting of 09-063r1 today,  section 5.6.5.3 has the timer changed
|from SNLT to SNTT from the original 2008 proposal.
Questions:
1) Is this in fact correct that the timer is changed
2) If so, there is still a reference to SNLT in 5.6.5.3.3 (a), I assume this
should also be SNTT.
    If SNLT in this section is correct, then SNLT is missing initialization
(starting) and any consequent actions on SNLT expiring in the PS states.
Secondly, regarding section 5.6.5.4.3 "footnote" of:
"Receipt of the ALIGN Received (1) message indicates that the connected phy
has been able to achieve dword synchronization with the previously negotiated
settings."
Questions:
1) Does this only apply to the 5.6.5.4.3 transition and not to the 5.6.5.3.3
transition to ALIGN1 state? Ie ALIGN0 state can transition to ALIGN
regardless of DWS sync?
   If so, I would like to suggest that maybe just 5.6.5.4.3 "a" should just
read:
    "a) If the DWS is synced, and this state receives an ALIGN Received (1)
message before the SNTT timer expires..."
    because other places in the phy spec the ALIGN Received message does not
imply the DWS is synced. I think it would be clearer and more consistent.
Please advise
Thanks,
Craig Stoops
ExpertIO, Inc. - "Your Storage Protocol Verification Experts"
www.expertio.com<<a href="http://www.expertio.com&gt">http://www.expertio.com&gt;


From craig at expertio.com  Wed Apr  1 08:38:23 2009
From: craig at expertio.com (Craig Stoops)
Date: Wed, 1 Apr 2009 08:38:23 -0700
Subject: 09-063r1  comment
Message-ID: <mailman.183.1441607348.22516.t10@sandbox.t10.org>

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

George,
Per our conversation this morning, I'm aware of the changes coming to the
SP11 state. 
However that doesn't address the issues I'm pointing out about the new SP32
and SP33. 
Thanks,
Craig
ExpertIO, Inc. - "Your Storage Protocol Verification Experts"
www.expertio.com
-----Original Message-----
From: Penokie, George [mailto:George.Penokie at lsi.com] 
Sent: Wednesday, April 01, 2009 6:06 AM
To: Craig Stoops; t10 at t10.org
Subject: RE: 09-063r1 comment
Craig,
That is an error in SAS-2 that will be fixed in revision 16 per the below
note that went out two weeks ago from Bill Martin.
Bye for now, 
George Penokie 
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901 
507-328-9017 
george.penokie at lsi.com 
  _____  
From: Craig Stoops [mailto:craig at expertio.com] 
Sent: Tuesday, March 31, 2009 7:31 PM
To: t10 at t10.org
Cc: Penokie, George
Subject: 09-063r1 comment
Hi George,
In your posting of 09-063r1 today,  section 5.6.5.3 has the timer changed
|from SNLT to SNTT from the original 2008 proposal.
Questions:
1) Is this in fact correct that the timer is changed
2) If so, there is still a reference to SNLT in 5.6.5.3.3 (a), I assume this
should also be SNTT. 
    If SNLT in this section is correct, then SNLT is missing initialization
(starting) and any consequent actions on SNLT expiring in the PS states.
Secondly, regarding section 5.6.5.4.3 "footnote" of:
"Receipt of the ALIGN Received (1) message indicates that the connected phy
has been able to achieve dword synchronization with the previously
negotiated settings."
Questions:
1) Does this only apply to the 5.6.5.4.3 transition and not to the 5.6.5.3.3
transition to ALIGN1 state? Ie ALIGN0 state can transition to ALIGN
regardless of DWS sync?
   If so, I would like to suggest that maybe just 5.6.5.4.3 "a" should just
read:
    "a) If the DWS is synced, and this state receives an ALIGN Received (1)
message before the SNTT timer expires..."
    because other places in the phy spec the ALIGN Received message does not
imply the DWS is synced. I think it would be clearer and more consistent.
Please advise
Thanks,
Craig Stoops
ExpertIO, Inc. - "Your Storage Protocol Verification Experts"
www.expertio.com


From billmc37 at ctesc.net  Wed Apr  1 09:16:22 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Wed, 01 Apr 2009 11:16:22 -0500
Subject: DVD+/-RW Dual Layer Proposal
Message-ID: <mailman.184.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Dear MMC Members:
At our last meeting, Katata-san of Pioneer made the claim that no 
company has ever marketed DVD-RW DL media nor drives that support it. He 
proposes that we remove it from MMC-6.
Similarly, we have seen neither media nor drives that support DVD+RW DL.
I am not sure that we should do this without further information. If you 
have more information about DVD+/-RW DL, please post to these reflectors.
Kind Regards,
Bill McFerrin, Chair MMC WG
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From billmc37 at ctesc.net  Wed Apr  1 10:10:02 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Wed, 01 Apr 2009 12:10:02 -0500
Subject: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
 still not consistent
Message-ID: <mailman.185.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi,
Katata-san is correct about this. There are a number of SPC3/4 
requirements with which ATAPI drives typically do not comply. This is 
permitted when the INQUIRY version number is set to zero.
I have been notified that SPC-3/4 requires that compliant devices 
support the REPORT LUNS command. It is most useless and unsupported on 
ATAPI and USB drives. We decided that I need to clarify the legal way to 
permit non-compliance with SPC-3/4. Addiitonally, I think that it is 
important that such drives include at least an MMC version descriptor.
Cheers,
Bill McFerrin
David Burg wrote:
>
> Hello,
>
>  
>
> Last year I reported an inconsistency on 4 fields between MMC and Mt 
> Fuji for the inquiry command response:
>
>  
>
> http://www.t10.org/ftp/t10/t10r/2008/r0804024.htm
>
>  
>
> The following meeting discussed and resolved the conflict on version 
> and response data format fields:
>
>  
>
> http://www.t10.org/ftp/t10/document.08/08-236r0.pdf
>
>  
>
> However it looks like the NormalACA and HiSup bits were overlooked. 
> Should these values be changed to 1b?
>
>  
>
> With regards,
>
>  
>
> David.
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From scsi.bbs at lsi.com  Wed Apr  1 10:32:24 2009
From: scsi.bbs at lsi.com (T10 Voting Administrator)
Date: Wed, 1 Apr 2009 11:32:24 -0600
Subject: SAM-4 FDIS: T10 Letter Ballot T10LBVOTE 09-135r0
Message-ID: <mailman.186.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Voting Administrator <scsi.bbs at lsi.com>
*
 2009/04/01 11:31:13
A T10 letter ballot (T10/09-135r0) has just been issued.
The topic of this letter ballot is:
  Recommendation on FDIS 14776-414 (SAM-4)
This ballot closes 2009/04/30 at 12:00 noon MDT.
If you are a T10 voting member, you should receive a separate
email with details of how to vote.
If you do not receive this email, it is likely that a spam
filter blocked its delivery. You can also find voting
instructions in the Members section of the T10 committee
web site.
Please do NOT reply to this automated email.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From scsi.bbs at lsi.com  Wed Apr  1 10:58:52 2009
From: scsi.bbs at lsi.com (T10 Voting Administrator)
Date: Wed, 1 Apr 2009 11:58:52 -0600
Subject: MMC-6: T10 Letter Ballot T10LBVOTE 09-137r0
Message-ID: <mailman.187.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Voting Administrator <scsi.bbs at lsi.com>
*
 2009/04/01 11:57:47
A T10 letter ballot (T10/09-137r0) has just been issued.
The topic of this letter ballot is:
  Forwarding MMC-6 to First Public Review
This ballot closes 2009/05/01 at 12:00 noon MDT.
If you are a T10 voting member, you should receive a separate
email with details of how to vote.
If you do not receive this email, it is likely that a spam
filter blocked its delivery. You can also find voting
instructions in the Members section of the T10 committee
web site.
Please do NOT reply to this automated email.
*
* 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  Wed Apr  1 11:59:46 2009
From: daviburg at windows.microsoft.com (David Burg)
Date: Wed, 1 Apr 2009 11:59:46 -0700
Subject: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
 still not consistent
Message-ID: <mailman.188.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Hello Bill,
Thank you for the response. What is the timeline to resolve this issue /
provide definitive answer what is or are the proper implementation(s)?
With regards,
David.
-----Original Message-----
From: Bill McFerrin [mailto:billmc37 at ctesc.net]
Sent: Wednesday, April 01, 2009 10:10 AM
To: David Burg
Cc: mtfuji5 at avc-pioneer.com; 'T10 Reflector'; Ope Aladekomo
Subject: Re: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
still not consistent
Hi,
Katata-san is correct about this. There are a number of SPC3/4
requirements with which ATAPI drives typically do not comply. This is
permitted when the INQUIRY version number is set to zero.
I have been notified that SPC-3/4 requires that compliant devices
support the REPORT LUNS command. It is most useless and unsupported on
ATAPI and USB drives. We decided that I need to clarify the legal way to
permit non-compliance with SPC-3/4. Addiitonally, I think that it is
important that such drives include at least an MMC version descriptor.
Cheers,
Bill McFerrin
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Monday, March 30, 2009 8:05 PM
To: mtfuji5 at avc-pioneer.com
Cc: 'T10 Reflector'; Ope Aladekomo
Subject: Re: [MtFuji] MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY
data are still not consistent
Hi David,
I think if you talk about ATAPI based ODD software, you may check the Version
field value as 00h.
If a device is designed as ATAPI device, the field is set to 00h.
If the device is designed as SAM device, the field is set to 06h (well.. 05h
may
be possible).
Best regards,
Keiji Katata
PIONEER CORP.
David Burg wrote:
>
> Hello,
>
>
>
> Last year I reported an inconsistency on 4 fields between MMC and Mt
> Fuji for the inquiry command response:
>
>
>
> http://www.t10.org/ftp/t10/t10r/2008/r0804024.htm
>
>
>
> The following meeting discussed and resolved the conflict on version
> and response data format fields:
>
>
>
> http://www.t10.org/ftp/t10/document.08/08-236r0.pdf
>
>
>
> However it looks like the NormalACA and HiSup bits were overlooked.
> Should these values be changed to 1b?
>
>
>
> With regards,
>
>
>
> David.
>
*
* 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  Wed Apr  1 14:51:57 2009
From: daviburg at windows.microsoft.com (David Burg)
Date: Wed, 1 Apr 2009 14:51:57 -0700
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
 Event'
Message-ID: <mailman.189.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Hi,
I'd rather see NEA clarify that have the host benchmark a device before it
may know how to use it. Spec needs to be clarified.
With regards,
David.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Monday, March 30, 2009 9:42 PM
To: mtfuji5 at avc-pioneer.com
Cc: T10 Reflector; Ope Aladekomo
Subject: Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
Hi david and Mike,
* Immed bit
Fuji spec says that if this bit is set to 0 and the device does not support
queuing the command shall be terminated as Check Condition. This is same with
MMC. Bill changed just name from Immed to Polled. They are same.
* the error reporting
I believe no device will report an error on Immed=0. Because Win98/ME do not
set
this bit to 1 any time. Some drive test system in PC/ODD venders still use
Win98, then any ODD that does not support queing will ignore this bit.
* no change event
NEA means no event is available to report. So some drive may use NEA=1 when
the
device has no (new) event to be reported. To detect supported Event you may
check "Supported Classes" field in Event Header. You need not use try and
check
error method.
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 daviburg at windows.microsoft.com  Wed Apr  1 15:11:00 2009
From: daviburg at windows.microsoft.com (David Burg)
Date: Wed, 1 Apr 2009 15:11:00 -0700
Subject: [MtFuji] DVD+/-RW Dual Layer Proposal
Message-ID: <mailman.190.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Hello,
At the Microsoft Windows Storage team, I believe we have not seen any of
either DVD+RW DL or DVD-RW DL, either drive or media. Given the availability
of BD-RE for a larger capacity rewritable optical storage, we would see it as
a positive move for the industry to 'retire' DVD+RW DL and DVD-RW DL before
they hit the market, thus avoid unnecessary complexity, user confusion, cost
to manufacture drives and maintain software.
With regards,
David.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of Bill McFerrin
Sent: Wednesday, April 01, 2009 9:16 AM
To: T10 Reflector; Mt.Fuji
Subject: [MtFuji] DVD+/-RW Dual Layer Proposal
Dear MMC Members:
At our last meeting, Katata-san of Pioneer made the claim that no
company has ever marketed DVD-RW DL media nor drives that support it. He
proposes that we remove it from MMC-6.
Similarly, we have seen neither media nor drives that support DVD+RW DL.
I am not sure that we should do this without further information. If you
have more information about DVD+/-RW DL, please post to these reflectors.
Kind Regards,
Bill McFerrin, Chair MMC WG
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From jl01881 at jcom.home.ne.jp  Wed Apr  1 18:58:11 2009
From: jl01881 at jcom.home.ne.jp (Y.Horiuchi)
Date: Thu, 2 Apr 2009 10:58:11 +0900
Subject: [MtFuji] DVD+/-RW Dual Layer Proposal
Message-ID: <mailman.191.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Y.Horiuchi" <jl01881 at jcom.home.ne.jp>
*
Hello  all,
>From Lenovo Storage procurement point of view, I could not see any support
for
DVD-RW DL, DVD+RW DL Slime drive in the markets.
I think there is no issue to remove these information from MMC-6.
Regards
---- Bill McFerrin <billmc37 at ctesc.net> $B$5$s$O=q$-$^$7$?(B: 
> Dear MMC Members:
> At our last meeting, Katata-san of Pioneer made the claim that no 
> company has ever marketed DVD-RW DL media nor drives that support it. He 
> proposes that we remove it from MMC-6.
> Similarly, we have seen neither media nor drives that support DVD+RW DL.
> 
> I am not sure that we should do this without further information. If you 
> have more information about DVD+/-RW DL, please post to these reflectors.
> 
> Kind Regards,
> Bill McFerrin, Chair MMC WG
--
Y.Horiuchi ($BKYFb!!9/90!K(B
Lenovo-J
jl01881 at jcom.home.ne.jp
(horiucy at lenovo.com)
*
* 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  Thu Apr  2 18:08:13 2009
From: daviburg at windows.microsoft.com (David Burg)
Date: Thu, 2 Apr 2009 18:08:13 -0700
Subject: Extending the time allocation for MMC in the Bellevue May meeting
Message-ID: <mailman.192.1441607348.22516.t10@sandbox.t10.org>

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

Hello,
Only 3 hours on Thursday have been planned for MMC meeting. Based on recent
reflector activity and expected additional joint proposal from Microsoft and
other company(ies), I believe this is not going to be enough time to cover
all material. I would like to suggest extending the time to a full day at
least.
Would that be feasible?
With regards,
David.


From keiji_katata at post.pioneer.co.jp  Thu Apr  2 21:55:09 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 3 Apr 2009 13:55:09 +0900
Subject: [MtFuji] Proposal for AN implementaion discussion meeting in Apr
Message-ID: <mailman.193.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi Horiuchi san and all,
Today I get a permission to attend T10 MMC at Seattle from my boss.
So it is good idea that we will have a meeting in Japan and will create a
good
meeting minutes, and then we will have a meeting in US.
And I have no problem Apr/15 in Shinagawa.
Could you send an annoucment for the meeting date, time and place?
I will preapre an agenda proposal based on items posted on reflector.
Best regards,
Keiji Katata
PIONEER CORP.
"Y.Horiuchi" <jl01881 at jcom.home.ne.jp>@avc-pioneer.com on 2009/04/03 12:04: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:
$B7oL>(B:  [MtFuji] Proposal for AN implementaion discussion meeting in Apr
Katata-san  and alll
I would like to request  AN implementaion discussion meeting in Apr with Mt
Fuji
people.
Could you recommend the availability for date? If threr is no poroblem , I
suggest Apr/16 th in Shinagawa, Tokyo.
Regards
--
Y.Horiuchi ($BKYFb!!9/90!K(B
Lenovo-J
jl01881 at jcom.home.ne.jp
(horiucy at lenovo.com)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Thu Apr  2 22:05:19 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 3 Apr 2009 14:05:19 +0900
Subject: [MtFuji] Extending the time allocation for MMC in the Bellevue May
 meeting
Message-ID: <mailman.194.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello David,
I personally have some interest in "additional joint proposal from Microsoft
and
other company(ies)". So if possible please send the information of it. If
possible before April 16 is appreciated.
I think we may have an additional day on May 6th at Redmond.
Anyway, I agree that 3 hours is short.
Best regards,
Keiji Katata
PIONEER CORP.
David Burg <daviburg at windows.microsoft.com>@avc-pioneer.com on 2009/04/03
10:08: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'" <mtfuji5 at avc-pioneer.com>, T10
Reflector
<t10 at t10.org>
cc:   Ope Aladekomo <Ope.Aladekomo at microsoft.com>
$B7oL>(B: [MtFuji] Extending the time allocation for MMC in the Bellevue
May meeting
Hello,
Only 3 hours on Thursday have been planned for MMC meeting. Based on recent
reflector activity and expected additional joint proposal from Microsoft and
other company(ies), I believe this is not going to be enough time to cover
all
material. I would like to suggest extending the time to a full day at least.
Would that be feasible?
With regards,
David.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From ai.takaharu at jp.panasonic.com  Thu Apr  2 22:13:31 2009
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Fri, 03 Apr 2009 14:13:31 +0900
Subject: [MtFuji] Proposal for AN implementaion discussion meeting in Apr
Message-ID: <mailman.195.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Katata-san,
Do you want to have the April meeting on 15th instead of 16th suggested
by Horiuchi-san?
With regard to May MMC meeting, the meeting room for MMC WG is reserved
only for 3 hours on Thursday morning. As David requested, we need to ask
Bill to extend the MMC meeting and to make it to full day MMC/Mt.Fuji
joint meeting, if we will add a new agenda. Since T10 plenary meeting is
scheduled on afternoon of Thursday, it should be shifted to Wednesday or
Tuesday.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: T10 Reflector <t10 at t10.org>
>Date: Fri, 3 Apr 2009 13:55:09 +0900
>Subject: Re: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
>
> 
> 
> Hi Horiuchi san and all,
> 
> Today I get a permission to attend T10 MMC at Seattle from my boss.
> So it is good idea that we will have a meeting in Japan and will create a
good
> meeting minutes, and then we will have a meeting in US.
> And I have no problem Apr/15 in Shinagawa.
> 
> Could you send an annoucment for the meeting date, time and place?
> I will preapre an agenda proposal based on items posted on reflector.
> 
> Best regards,
> 
> Keiji Katata
> PIONEER CORP.
> 
> 
> 
> 
> 
> "Y.Horiuchi" <jl01881 at jcom.home.ne.jp>@avc-pioneer.com on 2009/04/03
12:04: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:
> $B7oL>(B:  [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
> 
> Katata-san  and alll
> 
> I would like to request  AN implementaion discussion meeting in Apr with Mt
Fuji
> people.
> Could you recommend the availability for date? If threr is no poroblem , I
> suggest Apr/16 th in Shinagawa, Tokyo.
> 
> Regards
> 
> --
> Y.Horiuchi ($BKYFb!!9/90!K(B
> Lenovo-J
> jl01881 at jcom.home.ne.jp
> (horiucy at lenovo.com)
> 
> 
> 
----------------- End of the original message -----------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Thu Apr  2 22:33:44 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 3 Apr 2009 14:33:44 +0900
Subject: [MtFuji] Proposal for AN implementaion discussion meeting in Apr
Message-ID: <mailman.196.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi Ai san,
Yes it is.
April 16th is good for me.
1 day on Wednsday and original MMC 3 hours is good for me.
I would like to konw opinion of all members.
Could you send your opinion for April Fuji meeting schedule and May MMC/Fuji
meeting schedule?
Best regards,
Keiji Katata
PIONEER CORP.
Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2009/04/03
14:13:31
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 Reflector <t10 at t10.org>
$B7oL>(B:  Re: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
Hello Katata-san,
Do you want to have the April meeting on 15th instead of 16th suggested
by Horiuchi-san?
With regard to May MMC meeting, the meeting room for MMC WG is reserved
only for 3 hours on Thursday morning. As David requested, we need to ask
Bill to extend the MMC meeting and to make it to full day MMC/Mt.Fuji
joint meeting, if we will add a new agenda. Since T10 plenary meeting is
scheduled on afternoon of Thursday, it should be shifted to Wednesday or
Tuesday.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: T10 Reflector <t10 at t10.org>
>Date: Fri, 3 Apr 2009 13:55:09 +0900
>Subject: Re: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
>
>
>
> Hi Horiuchi san and all,
>
> Today I get a permission to attend T10 MMC at Seattle from my boss.
> So it is good idea that we will have a meeting in Japan and will create a
good
> meeting minutes, and then we will have a meeting in US.
> And I have no problem Apr/15 in Shinagawa.
>
> Could you send an annoucment for the meeting date, time and place?
> I will preapre an agenda proposal based on items posted on reflector.
>
> Best regards,
>
> Keiji Katata
> PIONEER CORP.
>
>
>
>
>
> "Y.Horiuchi" <jl01881 at jcom.home.ne.jp>@avc-pioneer.com on 2009/04/03
12:04: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:
> $B7oL>(B:  [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
>
> Katata-san  and alll
>
> I would like to request  AN implementaion discussion meeting in Apr with Mt
Fuji
> people.
> Could you recommend the availability for date? If threr is no poroblem , I
> suggest Apr/16 th in Shinagawa, Tokyo.
>
> Regards
>
> --
> Y.Horiuchi ($BKYFb!!9/90!K(B
> Lenovo-J
> jl01881 at jcom.home.ne.jp
> (horiucy at lenovo.com)
>
>
>
----------------- End of the original message -----------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Thu Apr  2 23:47:11 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 3 Apr 2009 15:47:11 +0900
Subject: Reflector cleanup notice
Message-ID: <mailman.197.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
The following people have bounced repeatedly and removed from mtfuji5
reflector:
Yo.Kabeya at jp.sony.com
Toshitaka.Nakashima at jp.sonynec-optiarc.com
They may get back on the reflector by sending a message to
majordomo at avc-pioneer.com with the following line in the message body:
subscribe mtfuji5
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  Fri Apr  3 01:34:39 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 3 Apr 2009 17:34:39 +0900
Subject: DVD+/-RW Dual Layer Proposal
Message-ID: <mailman.198.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi Bill,
May I correct your writing a little bit.
It was not proposal from Pioneer.
It was a report and a suggestion from me.
You said that it is not a small job to check the description of RW DL media
in
MMC6.
Then I reported that there was no disc product and no device product for RW
DL
media. This means that no one might not read the description of RW DL
carefully.
Because MMC6 will be submitted to ISO you might be prudent in dealing with
MMC6.
So I suggested that you may remove them.
Best regards,
Keiji Katata
PIONEER CORP.
Bill McFerrin <billmc37 at ctesc.net>@t10.org on 2009/04/02 01:16:22
$BAw?.<T(B:	  owner-t10 at t10.org
$B08 at h(B:  T10 Reflector <T10 at t10.org>, "Mt.Fuji" <mtfuji5 at avc-pioneer.com>
cc:
$B7oL>(B:  DVD+/-RW Dual Layer Proposal
* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Dear MMC Members:
At our last meeting, Katata-san of Pioneer made the claim that no
company has ever marketed DVD-RW DL media nor drives that support it. He
proposes that we remove it from MMC-6.
Similarly, we have seen neither media nor drives that support DVD+RW DL.
I am not sure that we should do this without further information. If you
have more information about DVD+/-RW DL, please post to these reflectors.
Kind Regards,
Bill McFerrin, Chair MMC WG
*
* 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 ai.takaharu at jp.panasonic.com  Fri Apr  3 03:54:46 2009
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Fri, 03 Apr 2009 19:54:46 +0900
Subject: [MtFuji] Proposal for AN implementaion discussion meeting in Apr
Message-ID: <mailman.199.1441607348.22516.t10@sandbox.t10.org>

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

Hello Mt.Fuji people,
Panasonic have prepared the meeting facility as follows.
Date and Time:
April 16th, 2009, 10AM-5PM JST
Place:
1st Tokyo Panasonic building
  See the attached map.
Meeting room #5 located on the 1st floor of the building
Address:
1-1-2, Shiba-koen, Minato-ku, Tokyo, 105-8581 Japan
Access:
Take the Mita Line of Toei Subway.
  http://www.kotsu.metro.tokyo.jp/english/index.html
Get off at Onarimon station.
Exit the exit number A3. You can find the building easily.
Registration:
Due to the security reason, registration is required in advance.
If you would like to attend the meeting, please let me know your name
and your company name by the end of 15th JST.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: T10 Reflector <t10 at t10.org>
>Date: Fri, 3 Apr 2009 14:33:44 +0900
>Subject: Re: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
>
> 
> 
> Hi Ai san,
> 
> Yes it is.
> April 16th is good for me.
> 1 day on Wednsday and original MMC 3 hours is good for me.
> 
> I would like to konw opinion of all members.
> Could you send your opinion for April Fuji meeting schedule and May
MMC/Fuji
> meeting schedule?
> 
> Best regards,
> 
> Keiji Katata
> PIONEER CORP.
> 
> 
> 
> 
> 
> Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2009/04/03
> 14:13:31
> 
> 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 Reflector <t10 at t10.org>
> $B7oL>(B:  Re: [MtFuji] Proposal for AN implementaion discussion meeting
in Apr
> 
> Hello Katata-san,
> 
> Do you want to have the April meeting on 15th instead of 16th suggested
> by Horiuchi-san?
> 
> 
> With regard to May MMC meeting, the meeting room for MMC WG is reserved
> only for 3 hours on Thursday morning. As David requested, we need to ask
> Bill to extend the MMC meeting and to make it to full day MMC/Mt.Fuji
> joint meeting, if we will add a new agenda. Since T10 plenary meeting is
> scheduled on afternoon of Thursday, it should be shifted to Wednesday or
> Tuesday.
> 
> 
> Best Regards,
> 
> Harry Ai
> VEBU,
> AVC Networks Company,
> Panasonic Corporation
> Osaka, Japan
> 
> 
> ---------------- Start of the original message ----------------
> >From: keiji_katata at post.pioneer.co.jp
> >To: mtfuji5 at avc-pioneer.com
> >Cc: T10 Reflector <t10 at t10.org>
> >Date: Fri, 3 Apr 2009 13:55:09 +0900
> >Subject: Re: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
> >
> >
> >
> > Hi Horiuchi san and all,
> >
> > Today I get a permission to attend T10 MMC at Seattle from my boss.
> > So it is good idea that we will have a meeting in Japan and will create a
good
> > meeting minutes, and then we will have a meeting in US.
> > And I have no problem Apr/15 in Shinagawa.
> >
> > Could you send an annoucment for the meeting date, time and place?
> > I will preapre an agenda proposal based on items posted on reflector.
> >
> > Best regards,
> >
> > Keiji Katata
> > PIONEER CORP.
> >
> >
> >
> >
> >
> > "Y.Horiuchi" <jl01881 at jcom.home.ne.jp>@avc-pioneer.com on 2009/04/03
12:04: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:
> > $B7oL>(B:  [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
> >
> > Katata-san	and alll
> >
> > I would like to request  AN implementaion discussion meeting in Apr with
Mt
> Fuji
> > people.
> > Could you recommend the availability for date? If threr is no poroblem ,
I
> > suggest Apr/16 th in Shinagawa, Tokyo.
> >
> > Regards
> >
> > --
> > Y.Horiuchi ($BKYFb!!9/90!K(B
> > Lenovo-J
> > jl01881 at jcom.home.ne.jp
> > (horiucy at lenovo.com)
> >
> >
> >
> 
> ----------------- End of the original message -----------------
> 
> 
> 
> 
> 
----------------- End of the original message -----------------


From keiji_katata at post.pioneer.co.jp  Fri Apr  3 04:42:09 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Fri, 3 Apr 2009 20:42:09 +0900
Subject: Posted: Agenda Proposal
Message-ID: <mailman.200.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted an agenda proposal on ftp.
ftp.avc-pioneer.com/Mtfuji_7/Proposal/Apr09/Agenda Apr09.doc
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 khattori at nero.com  Fri Apr  3 08:18:38 2009
From: khattori at nero.com (Katsuki Hattori)
Date: Sat, 4 Apr 2009 00:18:38 +0900
Subject: [MtFuji] Proposal for AN implementaion discussion meeting in Apr
Message-ID: <mailman.201.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Katsuki Hattori <khattori at nero.com>
*
Dear all,
BDA-TEG6 (MST6-1, MST6-2) meeting is held in Seoul on April 16 (13:30 -
18:00).  
Many persons will join in this meeting by telephone.
Isn't it better to shift a Fuji meeting from April 16?
Best regards,
Katsuki Hattori
NERO KK
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Friday, April 03, 2009 2:34 PM
To: mtfuji5 at avc-pioneer.com
Cc: T10 Reflector
Subject: Re: [MtFuji] Proposal for AN implementaion discussion meeting in Apr
Hi Ai san,
Yes it is.
April 16th is good for me.
1 day on Wednsday and original MMC 3 hours is good for me.
I would like to konw opinion of all members.
Could you send your opinion for April Fuji meeting schedule and May MMC/Fuji
meeting schedule?
Best regards,
Keiji Katata
PIONEER CORP.
Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2009/04/03
14:13:31
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 Reflector <t10 at t10.org>
$B7oL>(B:  Re: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
Hello Katata-san,
Do you want to have the April meeting on 15th instead of 16th suggested
by Horiuchi-san?
With regard to May MMC meeting, the meeting room for MMC WG is reserved
only for 3 hours on Thursday morning. As David requested, we need to ask
Bill to extend the MMC meeting and to make it to full day MMC/Mt.Fuji
joint meeting, if we will add a new agenda. Since T10 plenary meeting is
scheduled on afternoon of Thursday, it should be shifted to Wednesday or
Tuesday.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: T10 Reflector <t10 at t10.org>
>Date: Fri, 3 Apr 2009 13:55:09 +0900
>Subject: Re: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
>
>
>
> Hi Horiuchi san and all,
>
> Today I get a permission to attend T10 MMC at Seattle from my boss.
> So it is good idea that we will have a meeting in Japan and will create a
good
> meeting minutes, and then we will have a meeting in US.
> And I have no problem Apr/15 in Shinagawa.
>
> Could you send an annoucment for the meeting date, time and place?
> I will preapre an agenda proposal based on items posted on reflector.
>
> Best regards,
>
> Keiji Katata
> PIONEER CORP.
>
>
>
>
>
> "Y.Horiuchi" <jl01881 at jcom.home.ne.jp>@avc-pioneer.com on 2009/04/03
12:04: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:
> $B7oL>(B:  [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
>
> Katata-san  and alll
>
> I would like to request  AN implementaion discussion meeting in Apr with Mt
Fuji
> people.
> Could you recommend the availability for date? If threr is no poroblem , I
> suggest Apr/16 th in Shinagawa, Tokyo.
>
> Regards
>
> --
> Y.Horiuchi ($BKYFb!!9/90!K(B
> Lenovo-J
> jl01881 at jcom.home.ne.jp
> (horiucy at lenovo.com)
>
>
>
----------------- End of the original message -----------------
*
* 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 Apr  4 23:00:55 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 5 Apr 2009 00:00:55 -0600
Subject: Recent T10 documents uploaded since 2009/03/29
Message-ID: <mailman.202.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
ISO SAS-1.1 FDIS
(by: Ralph O. Weber)
T10/08-273r2   Uploaded: 2009/03/31   6137202 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-273r2.pdf
SPL: Low Power Options for SAS phys
(by: George Penokie)
T10/09-063r1   Uploaded: 2009/03/31   756483 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-063r1.pdf
Minutes of CAP Working Group - March 17-19, 2009
(by: Weber & Lohmeyer)
T10/09-103r1   Uploaded: 2009/03/31   56708 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-103r1.htm
Minutes of T10 Plenary Meeting #90 - March 19, 2009
(by: Weber & Lohmeyer)
T10/09-104r1   Uploaded: 2009/03/31   152464 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-104r1.htm
Minutes of T10 Plenary Meeting #90 - March 19, 2009
(by: Weber & Lohmeyer)
T10/09-104r1   Uploaded: 2009/03/31   369347 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-104r1.pdf
Letter Ballot on recommending approval of SAM-4 FDIS
(by: John Lohmeyer)
T10/09-135r0   Uploaded: 2009/04/01   84501 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-135r0.pdf
Letter Ballot on forwarding MMC-6 to first public review
(by: John Lohmeyer)
T10/09-137r0   Uploaded: 2009/04/01   85151 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-137r0.pdf
Working Drafts
--------------
MultiMedia Command Set - 6 (MMC-6)
(Editor: Bill McFerrin)
 Rev: 02b      Uploaded: 2009/04/01   4522992 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc6r02b.pdf
SAS Protocol Layer (SPL)
(Editor: George Penokie)
 Rev: 00       Uploaded: 2009/03/30   8113338 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl-r00.pdf
(Report generated on 2009/04/05 at 00:00:55)
*
* 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  Sun Apr  5 22:26:37 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 6 Apr 2009 14:26:37 +0900
Subject: [MtFuji] Proposal for AN implementation discussion meeting in Apr
Message-ID: <mailman.203.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello Hattori san,
I know the meeting of BDA. I think the meeting may not be important for
ordinary
members of Fuji reflector who does not have high responsibility for political
judgement about discussion items and schedule for the future meeting. And
opinion of the members may be collected later (May or June). (So many people
may
join by telephone)
I know your position. But sorry that I do not have other meeting facility for
the other day.
Do you have idea? (Personally 4/15, 4/17 are not good for me)
Best regards,
Keiji Katata
PIONEER CORP.
Katsuki Hattori <khattori at nero.com>@avc-pioneer.com on 2009/04/04 00:18:38
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  "'mtfuji5 at avc-pioneer.com'" <mtfuji5 at avc-pioneer.com>
cc:    "'T10 Reflector'" <t10 at t10.org>
$B7oL>(B:  RE: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
Dear all,
BDA-TEG6 (MST6-1, MST6-2) meeting is held in Seoul on April 16 (13:30 -
18:00).
Many persons will join in this meeting by telephone.
Isn't it better to shift a Fuji meeting from April 16?
Best regards,
Katsuki Hattori
NERO KK
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Friday, April 03, 2009 2:34 PM
To: mtfuji5 at avc-pioneer.com
Cc: T10 Reflector
Subject: Re: [MtFuji] Proposal for AN implementaion discussion meeting in Apr
Hi Ai san,
Yes it is.
April 16th is good for me.
1 day on Wednsday and original MMC 3 hours is good for me.
I would like to konw opinion of all members.
Could you send your opinion for April Fuji meeting schedule and May MMC/Fuji
meeting schedule?
Best regards,
Keiji Katata
PIONEER CORP.
Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2009/04/03
14:13:31
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 Reflector <t10 at t10.org>
$B7oL>(B:  Re: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
Hello Katata-san,
Do you want to have the April meeting on 15th instead of 16th suggested
by Horiuchi-san?
With regard to May MMC meeting, the meeting room for MMC WG is reserved
only for 3 hours on Thursday morning. As David requested, we need to ask
Bill to extend the MMC meeting and to make it to full day MMC/Mt.Fuji
joint meeting, if we will add a new agenda. Since T10 plenary meeting is
scheduled on afternoon of Thursday, it should be shifted to Wednesday or
Tuesday.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: T10 Reflector <t10 at t10.org>
>Date: Fri, 3 Apr 2009 13:55:09 +0900
>Subject: Re: [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
>
>
>
> Hi Horiuchi san and all,
>
> Today I get a permission to attend T10 MMC at Seattle from my boss.
> So it is good idea that we will have a meeting in Japan and will create a
good
> meeting minutes, and then we will have a meeting in US.
> And I have no problem Apr/15 in Shinagawa.
>
> Could you send an annoucment for the meeting date, time and place?
> I will preapre an agenda proposal based on items posted on reflector.
>
> Best regards,
>
> Keiji Katata
> PIONEER CORP.
>
>
>
>
>
> "Y.Horiuchi" <jl01881 at jcom.home.ne.jp>@avc-pioneer.com on 2009/04/03
12:04: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:
> $B7oL>(B:  [MtFuji] Proposal for AN implementaion discussion meeting in
Apr
>
> Katata-san  and alll
>
> I would like to request  AN implementaion discussion meeting in Apr with Mt
Fuji
> people.
> Could you recommend the availability for date? If threr is no poroblem , I
> suggest Apr/16 th in Shinagawa, Tokyo.
>
> Regards
>
> --
> Y.Horiuchi ($BKYFb!!9/90!K(B
> Lenovo-J
> jl01881 at jcom.home.ne.jp
> (horiucy at lenovo.com)
>
>
>
----------------- End of the original message -----------------
*
* 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 Apr  6 08:43:21 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 06 Apr 2009 09:43:21 -0600
Subject: Fwd: [Chairs] INCITS Technical Committee, Task Group and Study
  Group Membership Update - Final Notices Issued - Due April 15, 2009
Message-ID: <mailman.204.1441607348.22516.t10@sandbox.t10.org>

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

All T10 Voting and Advisory members need to pay their 2009 invoices by April
15th.
>From: "Barra, Lynn" <lbarra at itic.org>
>To: "chairs at standards.incits.org" <chairs at standards.incits.org>
>Date: Thu, 2 Apr 2009 16:00:11 -0600
>Subject: [Chairs] INCITS Technical Committee, Task Group and Study Group
> Membership Update - Final Notices Issued - Due April 15, 2009
>
>To Technical Committee, Task Group, and Study Group Chairs -
>		
> 
>Final notices were recently issued to all participating organizations whose
2009 service fee(s) have been identified as overdue.  Payment or purchase
orders must be received at the INCITS Secretariat not later than Wednesday,
April 15, 2009 to retain membership.
> 
>The INCITS Secretariat will forward information to each TC, TG, and SG Chair
of any voting and advisory memberships that may be canceled for failure to
pay the appropriate service fees.  
> 
>You may want to remind your committee of the above information and to
contact the Secretariat if there are any questions.
> 
>----------------------------------------------------------------------------
----------------------------------------------
> 
>Any organization may establish membership by contacting the INCITS
Secretariat at 202-595-2685, 202-626-5739, lbarra at itic.org or completing the
online membership request form at
<http://www.incits.org/membershi">http://www.incits.org/membership/mem_app.htm>http://www.incits.org/membershi
p/mem_app.htm. 
> 
>As a reminder, technical committee, task group, and study group members are
classified as voting members or advisory (non-voting) members as noted below
|from the INCITS/RD-2
(<http://www.incits.org/rd2/in081453.p">http://www.incits.org/rd2/in081453.pdf>http://www.incits.org/rd2/in081453.p
df):
> 
>Section 4.2.3.1.3
>Voting membership in TCs, TGs, and SGs is open to all directly and
materially affected parties that meet attendance and voting requirements and
pay the designated service fee(s). A representative of a prospective voting
member shall initially attend a meeting of the TC, TG, or SG without voting
privileges and reaffirm interest in the work of the TC, TG, or SG. Voting
privileges become effective with attendance at one of the next two successive
meetings and receipt by the Secretariat of the applicable fees for the
membership year. For a new subgroup, all attendees at the formation meeting
or second meeting shall be considered voting members, subject to the rules in
Section 4.2.3.2.  An organization with voting membership shall appoint one
and only one principal representative and may appoint one or more alternate
representatives.  In order to comply with ANSI requirements, while all
parties may participate in the discussion, only those organizations domiciled
in the U.S. may vote to establish a U.S. position on TAG matters.  
>
>Section 4.2.3.3.1
>All advisory memberships are non-voting memberships. Advisory members may
attend meetings, speak, and submit contributions. Advisory members shall
receive all electronically available documents, including meeting notices,
draft agendas and minutes. Other documents are not required to be distributed
to advisory members.
>If you have any questions or updated membership information, please contact
me.
> 
>Regards,
> 
>Lynn Barra
>Director, Standards Operations
>INCITS Secretariat
>Information Technology Industry Council
>1250 Eye St. NW
>Washington DC	20005
>T: 202-626-5739
> 
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907


From jtfrog at usa.net  Thu Apr  2 18:08:58 2009
From: jtfrog at usa.net (Jim Taylor)
Date: Thu, 2 Apr 2009 18:08:58 -0700
Subject: [MtFuji] DVD+/-RW Dual Layer Proposal
Message-ID: <mailman.205.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Jim Taylor" <jtfrog at usa.net>
*
Sonic/Roxio added support for DVD-RW DL to our software over a year ago,
however the media we received for testing did not last through the testing
process and we haven't seen any media since then.
We have never seen DVD+RW DL drives or media.
--
Jim Taylor
SVP & Chief Technologist, Sonic Solutions <www.sonic.com&gt;
Author of DVD Demystified and Blu-ray Disc Demystified
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]
On Behalf Of Bill McFerrin
Sent: Wednesday, April 01, 2009 9:16 AM
To: T10 Reflector; Mt.Fuji
Subject: [MtFuji] DVD+/-RW Dual Layer Proposal
Dear MMC Members:
At our last meeting, Katata-san of Pioneer made the claim that no 
company has ever marketed DVD-RW DL media nor drives that support it. He 
proposes that we remove it from MMC-6.
Similarly, we have seen neither media nor drives that support DVD+RW DL.
I am not sure that we should do this without further information. If you 
have more information about DVD+/-RW DL, please post to these reflectors.
Kind Regards,
Bill McFerrin, Chair MMC WG
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From richard.bohn at seagate.com  Mon Apr  6 10:44:47 2009
From: richard.bohn at seagate.com (richard.bohn at seagate.com)
Date: Mon, 6 Apr 2009 12:44:47 -0500
Subject: 09-063r1 and invalid dword / running disparity error counts
Message-ID: <mailman.206.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* richard.bohn at seagate.com
*
Hello all,
I have a question regarding the SAS interface power management
specification and the invalid dword / running disparity error counts from
the PHY ERROR LOG.
Currently the invalid dword and running disparity error counters are
defined as follows:
The INVALID DWORD COUNT field indicates the number of invalid dwords (see
3.1.121) that have been received
outside of phy reset sequences (i.e., between when the SP state machine
(see 6.8) sends a Phy Layer Ready
(SAS) confirmation or Phy Layer Ready (SATA) confirmation and when it sends
a Phy Layer Not Ready
confirmation to the link layer).
Does this wording need to be updated to account for state machine behavior
when the PHY enters its low power states? The new SP state machine as
proposed in 09-063r1 never sends a "Phy Layer Not Ready" confirmation to
the link layer when the PHY is powered down (although it does send a "Phy
Layer Ready" confirmation to the link layer when transitioning back to SP15
PHY_Ready). I imagine this was intentional so as to not reset the IR state
machine during power management modes.
I think once SP15 PHY_Ready is left, the invalid dword and running
disparity error counters should cease counting until SP15 PHY_Ready is
reached again. Thus, I think the current wording that defines those
counters as counting until a "Phy Layer Not Ready" message is received
needs to be updated to account for the window between entering SP31
SAS_PS_Low_Phy_Power and re-entering SP15 PHY_Ready.
Thanks,
Richard Bohn
Seagate Tech.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Mon Apr  6 11:20:11 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 6 Apr 2009 11:20:11 -0700
Subject: SSC-3: Clarifying sense data bits (08-406r2)
Message-ID: <mailman.207.1441607348.22516.t10@sandbox.t10.org>

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

I have uploaded changes to IBM's proposal on clarifying when sense data 
bits are set for tape drives.
I think this is close enough now that we will vote on it in the next 
meeting.
2009/04/06 12:13:14 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-406r2.pdf
Normally, the posting/archiving process takes about 30 minutes.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From mikeb at bustrace.com  Mon Apr  6 12:57:57 2009
From: mikeb at bustrace.com (Mike Berhan)
Date: Mon, 6 Apr 2009 12:57:57 -0700
Subject: MMC-6 2b - Real Time Streaming Feature Descriptor
Message-ID: <mailman.208.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
Bill,
A Real Time Streaming version descriptor issue remains in the latest draft
specification:
5.3.43, page 283:  Table 200 should show "Version = 0101b" instead of
"Version = 0100b".  Text below it should state that "The Version Field shall
be set to 0101b."
Version 4 of this descriptor does not include the "SMP" bit.  Refer to MMC-5
for v4 definition.  Refer to Mt. Fuji 7 for v5 definition.
Regards,
Mike
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Tue Apr  7 10:29:09 2009
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Tue, 7 Apr 2009 13:29:09 -0400
Subject: Announcement: Thin Provisioning Conference call
Message-ID: <mailman.209.1441607348.22516.t10@sandbox.t10.org>

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

This call will discuss the adjustments to the sbc3r18 text as it relates
to unmap operations being modeled as single LBA operations, where an
UNMAP request (for multiple LBAs) may cause multiple unmap operations.
This includes the discussion of the unmap granularity field and unmap
granularity offset field in the BLOCK LIMITS VPD page as introduced by
proposal 09-082r0.
Topic: Thin Provisioning 
Date: Wednesday, April 8, 2009 
Time: 12:00 pm, Pacific Daylight Time (GMT -07:00, San Francisco) 
Meeting number: 923 332 441 
Meeting password: TP 
Please click the link below to see more information, or to join the
meeting. 
NOTE: You do not need to register for a WebEx Account to attend this
meeting. Just click on the link below and use the Meeting password: TP 
https://netapp-meeting.webex.com/netapp-meeting/j.php?ED=116819307&UID=0
&PW=c2fafc6e3523
<https://netapp-meeting.webex.com/netapp-meeting/j.php?ED=116819307&UID=
0&PW=c2fafc6e3523>  
Teleconference: 1-888-765-3653 
ID = 595-2226# 
To contact frederick knight, send a message to knight at netapp.com
  


From billmc37 at ctesc.net  Tue Apr  7 12:14:53 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Tue, 07 Apr 2009 14:14:53 -0500
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.210.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi,
Your are right: The response is incorrect. Fuji agrees.
The more accurate wording you suggested (?If no event /of the requested 
notification class/ has occurred, ??) is a good thing. It might be 
useful to add a "for example".
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
> During our testing of Windows 7, our engineers noticed a difference in 
> the devices? implementation of GESN command response to say the same 
> ?no event? answer. Below is a capture of an 8 bytes answer from one 
> device and of an 4 bytes answer from another device.
>
> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
>
> We believe this complies to MMC?s:
>
> cid:image002.jpg at 01C9AC5C.CBEA04D0
>
> (One might want to be careful to clarify ?If no event /of the 
> requested notification class/ has occurred, ?? because event may occur 
> in another class and yet can?t be reported.)
>
> The other device responds:
>
> This does not seem allowed by the current spec, although it is not 
> completely obvious.
>
> Also, some software engineers thought they would get NEA = 1b and 4 
> bytes, based on the name of that bit ?Not Event Available?. >From an 
> English language point of view, there is indeed no event available. 
> However, the spec definition of the bit then contradicts with what one 
> would expect out of English language alone:
>
> ?If NEA (No Event Available) is set to one, the Drive supports none of 
> the requested notification classes. If NEA
>
> is set to zero, at least one of the requested notification classes is 
> supported.?
>
> This sounds more like ?No Requested Class Supported?.
>
> So, Microsoft believes this GESN section should be reviewed in detail 
> and clarified.
>
> With regards,
>
> David.
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From billmc37 at ctesc.net  Tue Apr  7 14:35:21 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Tue, 07 Apr 2009 16:35:21 -0500
Subject: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
 still not consistent
Message-ID: <mailman.211.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi,
This is a mess that may be only esoteric. At least I hope it is.
The Host must be able to trust something as axiomatic - inviolable and 
unchanging. INQUIRY data - at least some of it - should be that way.
Byte 0: Bits 4 through 0 specifies the device type (5 for MM devices) 
must be in the minimum set. It has been defined in this way since SCSI-2 
(1993). One could argue that it goes back to SCSI-1, but SCSI-1 did not 
define a device type 5.
Byte 2: This has been "version" since SPC-2 (2001). Its original 
definition as 3 separate version fields was established in SCSI-1 (1985).
SPC-2 tells us that when version = 0, the drive is claiming no 
compliance with any (SPC) standard.
Theoretically, you don't need to trust anything else. As a practical 
matter, the Host needs more "trustable" information, so I'll stop the 
theoretical viewpoint.
The main Fuji, MMC-5 and SPC-3 disagreement is byte 3. I blew it in 
MMC-5 with response data format (bits 3-0). I had requested a unique 
version for MMC and I didn't get it, but I failed to fix MMC-5. This is 
corrected in MMC-6. In the case of Fuji, the Host is supposed to "know" 
that the device is either SCSI or ATAPI in order to determine the actual 
meaning of byte 3 (bits7-4). That may be possible, but typically, USB 
connected devices report as if they were ATAPI. As the editor of MMC-6, 
I cannot change the field definitions of the INQUIRY data specified in 
SPC-3. T10 will not permit it. I would hope for a change to Fuji, but I 
that will also be difficult.
There are additional problems associated with version = 0. Luckily, 
these are resolved by specifying MM device behavior.  You probably don't 
care anyway. For example: the REPORT LUNS command is now mandatory 
according to SPC-3. We are permitted to not implement such a useless 
command when version = 0. I simply need to specify it.
Yes, this does not help much.
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
>  
>
> Last year I reported an inconsistency on 4 fields between MMC and Mt 
> Fuji for the inquiry command response:
>
>  
>
> http://www.t10.org/ftp/t10/t10r/2008/r0804024.htm
>
>  
>
> The following meeting discussed and resolved the conflict on version 
> and response data format fields:
>
>  
>
> http://www.t10.org/ftp/t10/document.08/08-236r0.pdf
>
>  
>
> However it looks like the NormalACA and HiSup bits were overlooked. 
> Should these values be changed to 1b?
>
>  
>
> With regards,
>
>  
>
> David.
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From billmc37 at ctesc.net  Tue Apr  7 14:49:37 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Tue, 07 Apr 2009 16:49:37 -0500
Subject: Extending the time allocation for MMC in the Bellevue May meeting
Message-ID: <mailman.212.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
OK,
I was hoping to be done with MMC-6 soon. I'll request that we have 
Wednesday again.
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
>  
>
> Only 3 hours on Thursday have been planned for MMC meeting. Based on 
> recent reflector activity and expected additional joint proposal from 
> Microsoft and other company(ies), I believe this is not going to be 
> enough time to cover all material. I would like to suggest extending 
> the time to a full day at least.
>
>  
>
> Would that be feasible?
>
>  
>
> With regards,
>
>  
>
> David.
>
>  
>
*
* 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  Tue Apr  7 16:33:20 2009
From: daviburg at windows.microsoft.com (David Burg)
Date: Tue, 7 Apr 2009 16:33:20 -0700
Subject: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
 still not consistent
Message-ID: <mailman.213.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Yes this does not help much, yet :-)
So what is the host supposed to do with these bits 7-4 of byte 3? Ignore
them? Do they have any practical use given the spec confusion?
With regards,
David.
-----Original Message-----
From: Bill McFerrin [mailto:billmc37 at ctesc.net]
Sent: Tuesday, April 07, 2009 2:35 PM
To: David Burg
Cc: mtfuji5 at avc-pioneer.com; 'T10 Reflector'; Ope Aladekomo
Subject: Re: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
still not consistent
Hi,
This is a mess that may be only esoteric. At least I hope it is.
The Host must be able to trust something as axiomatic - inviolable and
unchanging. INQUIRY data - at least some of it - should be that way.
Byte 0: Bits 4 through 0 specifies the device type (5 for MM devices)
must be in the minimum set. It has been defined in this way since SCSI-2
(1993). One could argue that it goes back to SCSI-1, but SCSI-1 did not
define a device type 5.
Byte 2: This has been "version" since SPC-2 (2001). Its original
definition as 3 separate version fields was established in SCSI-1 (1985).
SPC-2 tells us that when version = 0, the drive is claiming no
compliance with any (SPC) standard.
Theoretically, you don't need to trust anything else. As a practical
matter, the Host needs more "trustable" information, so I'll stop the
theoretical viewpoint.
The main Fuji, MMC-5 and SPC-3 disagreement is byte 3. I blew it in
MMC-5 with response data format (bits 3-0). I had requested a unique
version for MMC and I didn't get it, but I failed to fix MMC-5. This is
corrected in MMC-6. In the case of Fuji, the Host is supposed to "know"
that the device is either SCSI or ATAPI in order to determine the actual
meaning of byte 3 (bits7-4). That may be possible, but typically, USB
connected devices report as if they were ATAPI. As the editor of MMC-6,
I cannot change the field definitions of the INQUIRY data specified in
SPC-3. T10 will not permit it. I would hope for a change to Fuji, but I
that will also be difficult.
There are additional problems associated with version = 0. Luckily,
these are resolved by specifying MM device behavior.  You probably don't
care anyway. For example: the REPORT LUNS command is now mandatory
according to SPC-3. We are permitted to not implement such a useless
command when version = 0. I simply need to specify it.
Yes, this does not help much.
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
>
>
> Last year I reported an inconsistency on 4 fields between MMC and Mt
> Fuji for the inquiry command response:
>
>
>
> http://www.t10.org/ftp/t10/t10r/2008/r0804024.htm
>
>
>
> The following meeting discussed and resolved the conflict on version
> and response data format fields:
>
>
>
> http://www.t10.org/ftp/t10/document.08/08-236r0.pdf
>
>
>
> However it looks like the NormalACA and HiSup bits were overlooked.
> Should these values be changed to 1b?
>
>
>
> With regards,
>
>
>
> David.
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From ai.takaharu at jp.panasonic.com  Wed Apr  8 01:36:46 2009
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Wed, 08 Apr 2009 17:36:46 +0900
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.214.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello David,
[NEA bit]
The definition of this bit in MMC is;
    If NEA (No Event Available) is set to one, the Drive supports none
    of the requested notification classes. If NEA is set to zero, at
    least one of the requested notification classes is supported.
This bit of zero indicates that the drive supports none of the Classes
requested. It is independent from the existence of an occurred Event of
one of the requested Classes.
So, we agree with your following opinion.
> This sounds more like "No Requested Class Supported".
[Response Data length]
Regarding the reported parameter length, our understanding is same as
yours.
If the NEA is set to zero, one Event Descriptor must be transferred
even if no Event has occurred. In this case, the Event Descriptor Length
field is set to 0x0006.
If the NEA is set to one, no Event Descriptor is transferred. In this
case, the Event Descriptor Length field is set to 0x0002.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: David Burg <daviburg at windows.microsoft.com>
>To: "mtfuji5 at avc-pioneer.com" <mtfuji5 at avc-pioneer.com>, T10 Reflector
<t10 at t10.org>
>Cc: Ope Aladekomo <Ope.Aladekomo at microsoft.com>
>Date: Tue, 24 Mar 2009 13:18:01 -0700
>Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
>
> Hello,
> 
> During our testing of Windows 7, our engineers noticed a difference in the
devices' implementation of GESN command response to say the same 'no event'
answer. Below is a capture of an 8 bytes answer from one device and of an 4
bytes answer from another device.
> 
> 
> [cid:image001.png at 01C9AC80.A5F1FA20]
> 
> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
> 
> We believe this complies to MMC's:
> 
> [cid:image002.jpg at 01C9AC80.A5F1FA20]
> 
> (One might want to be careful to clarify "If no event of the requested
notification class has occurred, ..." because event may occur in another
class and yet can't be reported.)
> 
> The other device responds:
> 
> [cid:image003.png at 01C9AC80.A5F1FA20]
> 
> This does not seem allowed by the current spec, although it is not
completely obvious.
> 
> Also, some software engineers thought they would get NEA = 1b and 4 bytes,
based on the name of that bit "Not Event Available". From an English language
point of view, there is indeed no event available. However, the spec
definition of the bit then contradicts with what one would expect out of
English language alone:
> 
> "If NEA (No Event Available) is set to one, the Drive supports none of the
requested notification classes. If NEA
> is set to zero, at least one of the requested notification classes is
supported."
> 
> This sounds more like "No Requested Class Supported".
> 
> So, Microsoft believes this GESN section should be reviewed in detail and
clarified.
> 
> With regards,
> 
> David.
> 
----------------- End of the original message -----------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From keiji_katata at post.pioneer.co.jp  Wed Apr  8 21:45:36 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Thu, 9 Apr 2009 13:45:36 +0900
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.215.1441607348.22516.t10@sandbox.t10.org>

Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0904081_minutes_of_the_june_1998_mt._fuji_meeting.zip">minutes_of_the_june_1998_mt._fuji_meeting.zip</a>

Hi Ai san,
My understanding was wrong. Here are two reports.
1. Meeting minutes of NEA bit
Here is a meeting minutes that NEA bit was revised from 'No Event' bit.
2. Pioneer implementation
Some Pioneer drives reports this 4 bytes "00h 02h 00 7Eh".
Best regards,
Keiji Katata
PIONEER CORP.
(See attached file: Minutes of the June 1998 Mt. Fuji meeting.zip)
Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2009/04/08
17:36:46
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 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
$B7oL>(B:  Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
Hello David,
[NEA bit]
The definition of this bit in MMC is;
    If NEA (No Event Available) is set to one, the Drive supports none
    of the requested notification classes. If NEA is set to zero, at
    least one of the requested notification classes is supported.
This bit of zero indicates that the drive supports none of the Classes
requested. It is independent from the existence of an occurred Event of
one of the requested Classes.
So, we agree with your following opinion.
> This sounds more like "No Requested Class Supported".
[Response Data length]
Regarding the reported parameter length, our understanding is same as
yours.
If the NEA is set to zero, one Event Descriptor must be transferred
even if no Event has occurred. In this case, the Event Descriptor Length
field is set to 0x0006.
If the NEA is set to one, no Event Descriptor is transferred. In this
case, the Event Descriptor Length field is set to 0x0002.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: David Burg <daviburg at windows.microsoft.com>
>To: "mtfuji5 at avc-pioneer.com" <mtfuji5 at avc-pioneer.com>, T10 Reflector
<t10 at t10.org>
>Cc: Ope Aladekomo <Ope.Aladekomo at microsoft.com>
>Date: Tue, 24 Mar 2009 13:18:01 -0700
>Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
>
> Hello,
>
> During our testing of Windows 7, our engineers noticed a difference in the
devices' implementation of GESN command response to say the same 'no event'
answer. Below is a capture of an 8 bytes answer from one device and of an 4
bytes answer from another device.
>
>
> [cid:image001.png at 01C9AC80.A5F1FA20]
>
> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
>
> We believe this complies to MMC's:
>
> [cid:image002.jpg at 01C9AC80.A5F1FA20]
>
> (One might want to be careful to clarify "If no event of the requested
notification class has occurred, ..." because event may occur in another
class
and yet can't be reported.)
>
> The other device responds:
>
> [cid:image003.png at 01C9AC80.A5F1FA20]
>
> This does not seem allowed by the current spec, although it is not
completely
obvious.
>
> Also, some software engineers thought they would get NEA = 1b and 4 bytes,
based on the name of that bit "Not Event Available". From an English language
point of view, there is indeed no event available. However, the spec
definition
of the bit then contradicts with what one would expect out of English
language
alone:
>
> "If NEA (No Event Available) is set to one, the Drive supports none of the
requested notification classes. If NEA
> is set to zero, at least one of the requested notification classes is
supported."
>
> This sounds more like "No Requested Class Supported".
>
> So, Microsoft believes this GESN section should be reviewed in detail and
clarified.
>
> With regards,
>
> David.
>
----------------- End of the original message -----------------


From ai.takaharu at jp.panasonic.com  Thu Apr  9 00:10:28 2009
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Thu, 09 Apr 2009 16:10:28 +0900
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.216.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Katata-san,
Thank you for the important information.
> 1. Meeting minutes of NEA bit
> Here is a meeting minutes that NEA bit was revised from 'No Event' bit.
According to this minutes, The Notification Vlass field of 000b was
changed from "None of the requested event classes are supported" to
"Reserved". This decision was reflected to Fuji3v60.pdf. But later,
Fuji3v092.pdf, the definition of this value was returned to the original
one without any voting, maybe.
Form the theoretical point of view, this value should be Reserved
because the Notification Class 0 is Reserved and may be used for any
purpose in future. At that time, the value 000b must be used to report
the Class 0 event.
NEA was defined to report "None of the requested event classes are
supported" as the same meaning of the original definition of 000b of
Notification Vlass field.
I think we should discuss that the definition of the Notification Class
000b should be returned to Reserved or not.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: keiji_katata at post.pioneer.co.jp
>To: mtfuji5 at avc-pioneer.com
>Cc: T10 Reflector <t10 at t10.org>, Ope Aladekomo <Ope.Aladekomo at microsoft.com>
>Date: Thu, 9 Apr 2009 13:45:36 +0900
>Subject: Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
>
> Hi Ai san,
> 
> My understanding was wrong. Here are two reports.
> 
> 1. Meeting minutes of NEA bit
> Here is a meeting minutes that NEA bit was revised from 'No Event' bit.
> 
> 2. Pioneer implementation
> Some Pioneer drives reports this 4 bytes "00h 02h 00 7Eh".
> 
> Best regards,
> 
> Keiji Katata
> PIONEER CORP.
> 
> (See attached file: Minutes of the June 1998 Mt. Fuji meeting.zip)
> 
> 
> 
> 
> 
> Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2009/04/08
> 17:36:46
> 
> 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 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
> $B7oL>(B:  Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
> 
> Hello David,
> 
> 
> [NEA bit]
> The definition of this bit in MMC is;
>     If NEA (No Event Available) is set to one, the Drive supports none
>     of the requested notification classes. If NEA is set to zero, at
>     least one of the requested notification classes is supported.
> This bit of zero indicates that the drive supports none of the Classes
> requested. It is independent from the existence of an occurred Event of
> one of the requested Classes.
> So, we agree with your following opinion.
> 
> > This sounds more like "No Requested Class Supported".
> 
> 
> [Response Data length]
> Regarding the reported parameter length, our understanding is same as
> yours.
> If the NEA is set to zero, one Event Descriptor must be transferred
> even if no Event has occurred. In this case, the Event Descriptor Length
> field is set to 0x0006.
> If the NEA is set to one, no Event Descriptor is transferred. In this
> case, the Event Descriptor Length field is set to 0x0002.
> 
> 
> Best Regards,
> 
> Harry Ai
> VEBU,
> AVC Networks Company,
> Panasonic Corporation
> Osaka, Japan
> 
> 
> ---------------- Start of the original message ----------------
> >From: David Burg <daviburg at windows.microsoft.com>
> >To: "mtfuji5 at avc-pioneer.com" <mtfuji5 at avc-pioneer.com>, T10 Reflector
> <t10 at t10.org>
> >Cc: Ope Aladekomo <Ope.Aladekomo at microsoft.com>
> >Date: Tue, 24 Mar 2009 13:18:01 -0700
> >Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
> >
> > Hello,
> >
> > During our testing of Windows 7, our engineers noticed a difference in
the
> devices' implementation of GESN command response to say the same 'no event'
> answer. Below is a capture of an 8 bytes answer from one device and of an 4
> bytes answer from another device.
> >
> >
> > [cid:image001.png at 01C9AC80.A5F1FA20]
> >
> > (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
> >
> > We believe this complies to MMC's:
> >
> > [cid:image002.jpg at 01C9AC80.A5F1FA20]
> >
> > (One might want to be careful to clarify "If no event of the requested
> notification class has occurred, ..." because event may occur in another
class
> and yet can't be reported.)
> >
> > The other device responds:
> >
> > [cid:image003.png at 01C9AC80.A5F1FA20]
> >
> > This does not seem allowed by the current spec, although it is not
completely
> obvious.
> >
> > Also, some software engineers thought they would get NEA = 1b and 4
bytes,
> based on the name of that bit "Not Event Available". From an English
language
> point of view, there is indeed no event available. However, the spec
definition
> of the bit then contradicts with what one would expect out of English
language
> alone:
> >
> > "If NEA (No Event Available) is set to one, the Drive supports none of
the
> requested notification classes. If NEA
> > is set to zero, at least one of the requested notification classes is
> supported."
> >
> > This sounds more like "No Requested Class Supported".
> >
> > So, Microsoft believes this GESN section should be reviewed in detail and
> clarified.
> >
> > With regards,
> >
> > David.
> >
> 
> ----------------- End of the original message -----------------
> 
> 
> 
> 
----------------- End of the original message -----------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Frederick.Knight at netapp.com  Thu Apr  9 09:07:36 2009
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Thu, 9 Apr 2009 12:07:36 -0400
Subject: SAM ACA question
Message-ID: <mailman.217.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
SAM5r01 clause 7.4 Clear ACA contains the following statement:
"The service response for a CLEAR ACA request received from an I_T nexus
other than the faulted I_T nexus shall be FUNCTION REJECTED."
That statement seems to assume there is an ACA Active (a faulted I_T
nexus exists somewhere) - "other than THE faulted I_T nexus..."
If there is no faulted I_T nexus anywhere (ACA is not active), then will
a CLEAR ACA TMF still respond with FUNCTION REJECTED? or does it act
like ABORT TASK when the task is not in the task set and respond with
FUNCTION COMPLETE (since ACA is in fact cleared)?
host puts 2 commands "on the wire"
the first one gets CHECK CONDITION
the second one gets ACA ACTIVE
the target has a hard reset occur
host sends CLEAR ACA - what is the response?
	Fred Knight
*
* 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  Thu Apr  9 09:38:01 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 9 Apr 2009 09:38:01 -0700
Subject: 08-391r1 SSC-3: Letter Ballot comment IBM-L2 resolution uploaded
Message-ID: <mailman.218.1441607348.22516.t10@sandbox.t10.org>

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

I have updated the proposal to resolve letter ballot comment IBM-L2 (LOCK 
bit)
2009/04/08 20:57: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/cgi-bin/ac.pl?t=d&f=08-391r1.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From curtis.ballard at hp.com  Thu Apr  9 15:12:20 2009
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Thu, 9 Apr 2009 22:12:20 +0000
Subject: SMC-3 Working Group conference call 15 April, 8:00 AM PST
Message-ID: <mailman.219.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
Hewlett Packard will host a teleconference for the SMC-3 working group on
Wednesday, 15 April.  Contact details for that meeting follow.	Please
contact me for access numbers from any countries not listed.
The agenda is available at: http://www.t10.org/ftp/t10/smc-agnd.htm
and is posted in the following document:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-139r0.pdf
Curtis Ballard
Hewlett Packard
-----------------------------------------
Conference Call Passcode:	8983013
Conference Call Access Numbers:
U.S. (toll) dial-in number	281.964.1607
U.S. toll-free dial-in number	877.675.4345
Germany 			069-22-221-6176 or 800-664-7543
Netherlands - Amsterdam 	020-714-3562 or 0800-023-5079
Norway - Oslo			21-033-192 or 800-18-430
United Kingdom			0844-579-0686 or 0808-238-0672
Virtual Rooms Link:
https://www.rooms.hp.com/attend/default.aspx?key=EH57CE6NLK 
*
* 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  Thu Apr  9 15:46:19 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 9 Apr 2009 15:46:19 -0700
Subject: SMC-3: Action Items Reminder
Message-ID: <mailman.220.1441607348.22516.t10@sandbox.t10.org>

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

This is a REMINDER to the SMC-3 Working Group.
The following is the list of Action Items found in the last SMC-3 Minutes.
07-017		[Group] Make sure the all the functionality of Read 
Element Status is covered by the Report Element Information command 
(06-272) and the Report Volume Information command and examine if an 
informative annex to map the RES command onto these is appropriate. 
[Reminder to do as final step]
07-042		[Paul Suhler] Write a proposal for the commands which the 
cached ready state in ADC may be used.
14Jan08-09	Curtis Ballard to propose meaning of RANDOM POSITIONING 
ERROR
14Jan08-11	Kevin Butt to propose meaning of OPERATOR MEDIUM REMOVAL 
REQUEST
14July08-01	Geoff Barton to create a proposal for the use of the NOT 
READY TO READY TRANSITION sense code.
20Aug08-05	Kevin to report to Noud what causes the LOGICAL UNIT NOT 
READY, OFFLINE error code to be reported. This needs to be in light of 
both ADC and SMC.
08Sept08-02	Noud Snelder to incorporate SMC-3 Use of INCOMPATIBLE 
MEDIUM INSTALLED (08-270r0) into SMC-3
03Nov08-02	Noud Snelder to incorporate SMC-3: Medium Magazine Error 
Codes (07-372r4) into SMC-3.
16Mar09-01	Curtis to revise SMC-3 Cleaning error codes (08-201r2) and 
post.
16Mar09-02	Noud to incorporate SMC-3 Cleaning error codes (08-201r3)
16Mar09-03	Curtis to revise SMC-3 TapeAlert Enhancements (09-109r0) 
and post
16Mar09-04	Noud to revise SMC-3 Use of NOT READY error codes 
(08-320r0) and post
16Mar09-05	All to investigate proposed error codes in 08-271r2 for 
preferred sense code and errors.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From kdbutt at us.ibm.com  Thu Apr  9 15:45:24 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 9 Apr 2009 15:45:24 -0700
Subject: 09-140r0 SPC-4: Proving SA Ownership in CDB
Message-ID: <mailman.221.1441607348.22516.t10@sandbox.t10.org>

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

I have uploaded the proposal I talked about in March CAP meeting.  I 
re-uploaded this a few minutes ago, so if you downloaded it earlier today 
you will want to go get the new one.
2009/04/09 16:24: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/cgi-bin/ac.pl?t=d&f=09-140r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From curtis.ballard at hp.com  Thu Apr  9 15:12:20 2009
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Thu, 9 Apr 2009 22:12:20 +0000
Subject: SMC-3 Working Group conference call 15 April, 8:00 AM PST
Message-ID: <mailman.222.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
Hewlett Packard will host a teleconference for the SMC-3 working group on
Wednesday, 15 April.  Contact details for that meeting follow.	Please
contact me for access numbers from any countries not listed.
The agenda is available at: http://www.t10.org/ftp/t10/smc-agnd.htm
and is posted in the following document:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-139r0.pdf
Curtis Ballard
Hewlett Packard
-----------------------------------------
Conference Call Passcode:	8983013
Conference Call Access Numbers:
U.S. (toll) dial-in number	281.964.1607
U.S. toll-free dial-in number	877.675.4345
Germany 			069-22-221-6176 or 800-664-7543
Netherlands - Amsterdam 	020-714-3562 or 0800-023-5079
Norway - Oslo			21-033-192 or 800-18-430
United Kingdom			0844-579-0686 or 0808-238-0672
Virtual Rooms Link:
https://www.rooms.hp.com/attend/default.aspx?key=EH57CE6NLK 
*
* 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  Thu Apr  9 15:46:19 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 9 Apr 2009 15:46:19 -0700
Subject: SMC-3: Action Items Reminder
Message-ID: <mailman.223.1441607348.22516.t10@sandbox.t10.org>

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

This is a REMINDER to the SMC-3 Working Group.
The following is the list of Action Items found in the last SMC-3 Minutes.
07-017		[Group] Make sure the all the functionality of Read 
Element Status is covered by the Report Element Information command 
(06-272) and the Report Volume Information command and examine if an 
informative annex to map the RES command onto these is appropriate. 
[Reminder to do as final step]
07-042		[Paul Suhler] Write a proposal for the commands which the 
cached ready state in ADC may be used.
14Jan08-09	Curtis Ballard to propose meaning of RANDOM POSITIONING 
ERROR
14Jan08-11	Kevin Butt to propose meaning of OPERATOR MEDIUM REMOVAL 
REQUEST
14July08-01	Geoff Barton to create a proposal for the use of the NOT 
READY TO READY TRANSITION sense code.
20Aug08-05	Kevin to report to Noud what causes the LOGICAL UNIT NOT 
READY, OFFLINE error code to be reported. This needs to be in light of 
both ADC and SMC.
08Sept08-02	Noud Snelder to incorporate SMC-3 Use of INCOMPATIBLE 
MEDIUM INSTALLED (08-270r0) into SMC-3
03Nov08-02	Noud Snelder to incorporate SMC-3: Medium Magazine Error 
Codes (07-372r4) into SMC-3.
16Mar09-01	Curtis to revise SMC-3 Cleaning error codes (08-201r2) and 
post.
16Mar09-02	Noud to incorporate SMC-3 Cleaning error codes (08-201r3)
16Mar09-03	Curtis to revise SMC-3 TapeAlert Enhancements (09-109r0) 
and post
16Mar09-04	Noud to revise SMC-3 Use of NOT READY error codes 
(08-320r0) and post
16Mar09-05	All to investigate proposed error codes in 08-271r2 for 
preferred sense code and errors.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From billmc37 at ctesc.net  Tue Apr  7 14:35:21 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Tue, 7 Apr 2009 16:35:21 -0500
Subject: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
 still not consistent
Message-ID: <mailman.224.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi,
This is a mess that may be only esoteric. At least I hope it is.
The Host must be able to trust something as axiomatic - inviolable and 
unchanging. INQUIRY data - at least some of it - should be that way.
Byte 0: Bits 4 through 0 specifies the device type (5 for MM devices) 
must be in the minimum set. It has been defined in this way since SCSI-2 
(1993). One could argue that it goes back to SCSI-1, but SCSI-1 did not 
define a device type 5.
Byte 2: This has been "version" since SPC-2 (2001). Its original 
definition as 3 separate version fields was established in SCSI-1 (1985).
SPC-2 tells us that when version = 0, the drive is claiming no 
compliance with any (SPC) standard.
Theoretically, you don't need to trust anything else. As a practical 
matter, the Host needs more "trustable" information, so I'll stop the 
theoretical viewpoint.
The main Fuji, MMC-5 and SPC-3 disagreement is byte 3. I blew it in 
MMC-5 with response data format (bits 3-0). I had requested a unique 
version for MMC and I didn't get it, but I failed to fix MMC-5. This is 
corrected in MMC-6. In the case of Fuji, the Host is supposed to "know" 
that the device is either SCSI or ATAPI in order to determine the actual 
meaning of byte 3 (bits7-4). That may be possible, but typically, USB 
connected devices report as if they were ATAPI. As the editor of MMC-6, 
I cannot change the field definitions of the INQUIRY data specified in 
SPC-3. T10 will not permit it. I would hope for a change to Fuji, but I 
that will also be difficult.
There are additional problems associated with version = 0. Luckily, 
these are resolved by specifying MM device behavior.  You probably don't 
care anyway. For example: the REPORT LUNS command is now mandatory 
according to SPC-3. We are permitted to not implement such a useless 
command when version = 0. I simply need to specify it.
Yes, this does not help much.
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
>  
>
> Last year I reported an inconsistency on 4 fields between MMC and Mt 
> Fuji for the inquiry command response:
>
>  
>
> http://www.t10.org/ftp/t10/t10r/2008/r0804024.htm
>
>  
>
> The following meeting discussed and resolved the conflict on version 
> and response data format fields:
>
>  
>
> http://www.t10.org/ftp/t10/document.08/08-236r0.pdf
>
>  
>
> However it looks like the NormalACA and HiSup bits were overlooked. 
> Should these values be changed to 1b?
>
>  
>
> With regards,
>
>  
>
> David.
>
*
* 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 billmc37 at ctesc.net  Tue Apr  7 14:49:37 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Tue, 7 Apr 2009 16:49:37 -0500
Subject: [MtFuji] Re: Extending the time allocation for MMC in the Bellevue May meeting
Message-ID: <mailman.225.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
OK,
I was hoping to be done with MMC-6 soon. I'll request that we have 
Wednesday again.
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
>  
>
> Only 3 hours on Thursday have been planned for MMC meeting. Based on 
> recent reflector activity and expected additional joint proposal from 
> Microsoft and other company(ies), I believe this is not going to be 
> enough time to cover all material. I would like to suggest extending 
> the time to a full day at least.
>
>  
>
> Would that be feasible?
>
>  
>
> With regards,
>
>  
>
> David.
>
>  
>
*
* 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  Tue Apr  7 16:33:20 2009
From: daviburg at windows.microsoft.com (David Burg)
Date: Tue, 7 Apr 2009 16:33:20 -0700
Subject: [MtFuji] RE: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
 still not consistent
Message-ID: <mailman.226.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Yes this does not help much, yet :-)
So what is the host supposed to do with these bits 7-4 of byte 3? Ignore
them? Do they have any practical use given the spec confusion?
With regards,
David.
-----Original Message-----
From: Bill McFerrin [mailto:billmc37 at ctesc.net]
Sent: Tuesday, April 07, 2009 2:35 PM
To: David Burg
Cc: mtfuji5 at avc-pioneer.com; 'T10 Reflector'; Ope Aladekomo
Subject: Re: MMC / Mt Fuji:: NormalACA and HiSup bits in INQUIRY data are
still not consistent
Hi,
This is a mess that may be only esoteric. At least I hope it is.
The Host must be able to trust something as axiomatic - inviolable and
unchanging. INQUIRY data - at least some of it - should be that way.
Byte 0: Bits 4 through 0 specifies the device type (5 for MM devices)
must be in the minimum set. It has been defined in this way since SCSI-2
(1993). One could argue that it goes back to SCSI-1, but SCSI-1 did not
define a device type 5.
Byte 2: This has been "version" since SPC-2 (2001). Its original
definition as 3 separate version fields was established in SCSI-1 (1985).
SPC-2 tells us that when version = 0, the drive is claiming no
compliance with any (SPC) standard.
Theoretically, you don't need to trust anything else. As a practical
matter, the Host needs more "trustable" information, so I'll stop the
theoretical viewpoint.
The main Fuji, MMC-5 and SPC-3 disagreement is byte 3. I blew it in
MMC-5 with response data format (bits 3-0). I had requested a unique
version for MMC and I didn't get it, but I failed to fix MMC-5. This is
corrected in MMC-6. In the case of Fuji, the Host is supposed to "know"
that the device is either SCSI or ATAPI in order to determine the actual
meaning of byte 3 (bits7-4). That may be possible, but typically, USB
connected devices report as if they were ATAPI. As the editor of MMC-6,
I cannot change the field definitions of the INQUIRY data specified in
SPC-3. T10 will not permit it. I would hope for a change to Fuji, but I
that will also be difficult.
There are additional problems associated with version = 0. Luckily,
these are resolved by specifying MM device behavior.  You probably don't
care anyway. For example: the REPORT LUNS command is now mandatory
according to SPC-3. We are permitted to not implement such a useless
command when version = 0. I simply need to specify it.
Yes, this does not help much.
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
>
>
> Last year I reported an inconsistency on 4 fields between MMC and Mt
> Fuji for the inquiry command response:
>
>
>
> http://www.t10.org/ftp/t10/t10r/2008/r0804024.htm
>
>
>
> The following meeting discussed and resolved the conflict on version
> and response data format fields:
>
>
>
> http://www.t10.org/ftp/t10/document.08/08-236r0.pdf
>
>
>
> However it looks like the NormalACA and HiSup bits were overlooked.
> Should these values be changed to 1b?
>
>
>
> With regards,
>
>
>
> David.
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From billmc37 at ctesc.net  Tue Apr  7 12:14:53 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Tue, 7 Apr 2009 14:14:53 -0500
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.227.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi,
Your are right: The response is incorrect. Fuji agrees.
The more accurate wording you suggested (?If no event /of the requested 
notification class/ has occurred, ??) is a good thing. It might be 
useful to add a "for example".
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
> During our testing of Windows 7, our engineers noticed a difference in 
> the devices? implementation of GESN command response to say the same 
> ?no event? answer. Below is a capture of an 8 bytes answer from one 
> device and of an 4 bytes answer from another device.
>
> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
>
> We believe this complies to MMC?s:
>
> cid:image002.jpg at 01C9AC5C.CBEA04D0
>
> (One might want to be careful to clarify ?If no event /of the 
> requested notification class/ has occurred, ?? because event may occur 
> in another class and yet can?t be reported.)
>
> The other device responds:
>
> This does not seem allowed by the current spec, although it is not 
> completely obvious.
>
> Also, some software engineers thought they would get NEA = 1b and 4 
> bytes, based on the name of that bit ?Not Event Available?. >From an 
> English language point of view, there is indeed no event available. 
> However, the spec definition of the bit then contradicts with what one 
> would expect out of English language alone:
>
> ?If NEA (No Event Available) is set to one, the Drive supports none of 
> the requested notification classes. If NEA
>
> is set to zero, at least one of the requested notification classes is 
> supported.?
>
> This sounds more like ?No Requested Class Supported?.
>
> So, Microsoft believes this GESN section should be reviewed in detail 
> and clarified.
>
> With regards,
>
> David.
>
*
* 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 billmc37 at ctesc.net  Tue Apr  7 12:14:53 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Tue, 7 Apr 2009 14:14:53 -0500
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.228.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi,
Your are right: The response is incorrect. Fuji agrees.
The more accurate wording you suggested (?If no event /of the requested 
notification class/ has occurred, ??) is a good thing. It might be 
useful to add a "for example".
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
> During our testing of Windows 7, our engineers noticed a difference in 
> the devices? implementation of GESN command response to say the same 
> ?no event? answer. Below is a capture of an 8 bytes answer from one 
> device and of an 4 bytes answer from another device.
>
> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
>
> We believe this complies to MMC?s:
>
> cid:image002.jpg at 01C9AC5C.CBEA04D0
>
> (One might want to be careful to clarify ?If no event /of the 
> requested notification class/ has occurred, ?? because event may occur 
> in another class and yet can?t be reported.)
>
> The other device responds:
>
> This does not seem allowed by the current spec, although it is not 
> completely obvious.
>
> Also, some software engineers thought they would get NEA = 1b and 4 
> bytes, based on the name of that bit ?Not Event Available?. >From an 
> English language point of view, there is indeed no event available. 
> However, the spec definition of the bit then contradicts with what one 
> would expect out of English language alone:
>
> ?If NEA (No Event Available) is set to one, the Drive supports none of 
> the requested notification classes. If NEA
>
> is set to zero, at least one of the requested notification classes is 
> supported.?
>
> This sounds more like ?No Requested Class Supported?.
>
> So, Microsoft believes this GESN section should be reviewed in detail 
> and clarified.
>
> With regards,
>
> David.
>
*
* 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  Thu Apr  9 09:38:01 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 9 Apr 2009 09:38:01 -0700
Subject: 08-391r1 SSC-3: Letter Ballot comment IBM-L2 resolution uploaded
Message-ID: <mailman.229.1441607348.22516.t10@sandbox.t10.org>

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

I have updated the proposal to resolve letter ballot comment IBM-L2 (LOCK 
bit)
2009/04/08 20:57: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/cgi-bin/ac.pl?t=d&f=08-391r1.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From ai.takaharu at jp.panasonic.com  Wed Apr  8 01:36:46 2009
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Wed, 8 Apr 2009 17:36:46 +0900
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.230.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello David,
[NEA bit]
The definition of this bit in MMC is;
    If NEA (No Event Available) is set to one, the Drive supports none
    of the requested notification classes. If NEA is set to zero, at
    least one of the requested notification classes is supported.
This bit of zero indicates that the drive supports none of the Classes
requested. It is independent from the existence of an occurred Event of
one of the requested Classes.
So, we agree with your following opinion.
> This sounds more like "No Requested Class Supported".
[Response Data length]
Regarding the reported parameter length, our understanding is same as
yours.
If the NEA is set to zero, one Event Descriptor must be transferred
even if no Event has occurred. In this case, the Event Descriptor Length
field is set to 0x0006.
If the NEA is set to one, no Event Descriptor is transferred. In this
case, the Event Descriptor Length field is set to 0x0002.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: David Burg <daviburg at windows.microsoft.com>
>To: "mtfuji5 at avc-pioneer.com" <mtfuji5 at avc-pioneer.com>, T10 Reflector
<t10 at t10.org>
>Cc: Ope Aladekomo <Ope.Aladekomo at microsoft.com>
>Date: Tue, 24 Mar 2009 13:18:01 -0700
>Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
>
> Hello,
> 
> During our testing of Windows 7, our engineers noticed a difference in the
devices' implementation of GESN command response to say the same 'no event'
answer. Below is a capture of an 8 bytes answer from one device and of an 4
bytes answer from another device.
> 
> 
> [cid:image001.png at 01C9AC80.A5F1FA20]
> 
> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
> 
> We believe this complies to MMC's:
> 
> [cid:image002.jpg at 01C9AC80.A5F1FA20]
> 
> (One might want to be careful to clarify "If no event of the requested
notification class has occurred, ..." because event may occur in another
class and yet can't be reported.)
> 
> The other device responds:
> 
> [cid:image003.png at 01C9AC80.A5F1FA20]
> 
> This does not seem allowed by the current spec, although it is not
completely obvious.
> 
> Also, some software engineers thought they would get NEA = 1b and 4 bytes,
based on the name of that bit "Not Event Available". From an English language
point of view, there is indeed no event available. However, the spec
definition of the bit then contradicts with what one would expect out of
English language alone:
> 
> "If NEA (No Event Available) is set to one, the Drive supports none of the
requested notification classes. If NEA
> is set to zero, at least one of the requested notification classes is
supported."
> 
> This sounds more like "No Requested Class Supported".
> 
> So, Microsoft believes this GESN section should be reviewed in detail and
clarified.
> 
> With regards,
> 
> David.
> 
----------------- End of the original message -----------------
*
* 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 Apr 11 23:00:51 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 12 Apr 2009 00:00:51 -0600
Subject: Recent T10 documents uploaded since 2009/04/05
Message-ID: <mailman.231.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SMC-3, Report Element Information
(by: Curtis Ballard)
T10/08-066r7   Uploaded: 2009/04/08   127855 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-066r7.pdf
SMC-3 Report Volume Information
(by: Curtis Ballard)
T10/08-215r4   Uploaded: 2009/04/08   0 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-215r4.pdf
SSC-3: Letter Ballot comment IBM-L2 resolution
(by: Kevin Butt)
T10/08-391r1   Uploaded: 2009/04/08   213315 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-391r1.pdf
SSC-3: Clarifying when sense data bits are set
(by: Kevin Butt)
T10/08-406r2   Uploaded: 2009/04/06   90289 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-406r2.pdf
Tyco Electronics External 8x Mini SAS w/ 4x Modular Capability
(by: Scott Shuey)
T10/09-014r3   Uploaded: 2009/04/07   2653354 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-014r3.pdf
SAS-2.1 Interconnect Budget Analysis for 12Gbps Signaling
(by: Barry Olawsky)
T10/09-123r0   Uploaded: 2009/04/08   719212 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-123r0.pdf
SMC-3 Teleconference Agenda for April 15, 2009
(by: Curtis Ballard)
T10/09-139r0   Uploaded: 2009/04/09   12283 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-139r0.pdf
SPC-4: Proving SA Ownership in CDB
(by: Kevin Butt)
T10/09-140r0   Uploaded: 2009/04/09   96177 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-140r0.pdf
Minutes of CAP TP Thresholding call April 8, 2009
(by: Frederick Knight)
T10/09-142r0   Uploaded: 2009/04/10   23797 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-142r0.pdf
Working Drafts
--------------
(Report generated on 2009/04/12 at 00:00:51)
*
* 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  Sun Apr 12 19:46:24 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 13 Apr 2009 11:46:24 +0900
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.232.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi Bill,
I might misunderstand this item.
Bill, let me know when did you add this sentence in MMC?
Could you tell me the file name of the MMC meeting minutes?
Best regards,
Keiji Katata
PIONEER CORP.
Bill McFerrin <billmc37 at ctesc.net>@avc-pioneer.com on 2009/04/08 04:14:53
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 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
$B7oL>(B:  Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi,
Your are right: The response is incorrect. Fuji agrees.
The more accurate wording you suggested ($B!H(BIf no event /of the
requested
notification class/ has occurred, $B!D!I(B) is a good thing. It might be
useful to add a "for example".
Cheers,
Bill
David Burg wrote:
>
> Hello,
>
> During our testing of Windows 7, our engineers noticed a difference in
> the devices$B!G(B implementation of GESN command response to say the same
> $B!F(Bno event$B!G(B answer. Below is a capture of an 8 bytes answer
|from one
> device and of an 4 bytes answer from another device.
>
> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
>
> We believe this complies to MMC$B!G(Bs:
>
> cid:image002.jpg at 01C9AC5C.CBEA04D0
>
> (One might want to be careful to clarify $B!H(BIf no event /of the
> requested notification class/ has occurred, $B!D!I(B because event may
occur
> in another class and yet can$B!G(Bt be reported.)
>
> The other device responds:
>
> This does not seem allowed by the current spec, although it is not
> completely obvious.
>
> Also, some software engineers thought they would get NEA = 1b and 4
> bytes, based on the name of that bit $B!H(BNot Event Available$B!I(B.
>From an
> English language point of view, there is indeed no event available.
> However, the spec definition of the bit then contradicts with what one
> would expect out of English language alone:
>
> $B!H(BIf NEA (No Event Available) is set to one, the Drive supports none
of
> the requested notification classes. If NEA
>
> is set to zero, at least one of the requested notification classes is
> supported.$B!I(B
>
> This sounds more like $B!H(BNo Requested Class Supported$B!I(B.
>
> So, Microsoft believes this GESN section should be reviewed in detail
> and clarified.
>
> With regards,
>
> David.
>
*
* 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 billmc37 at ctesc.net  Mon Apr 13 08:54:25 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Mon, 13 Apr 2009 10:54:25 -0500
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.233.1441607348.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi
The sentence: "If no event / of the requested notification class / has
occurred, ..." was David Burg's attempt to be clear about what he
believes to be the meaning of the text. It is not in any version of MMC.
Since some people are confused, clarification is needed. It appears that
David's proposed sentence is correct.
Cheers,
Bill McFerrin
keiji_katata at post.pioneer.co.jp wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * keiji_katata at post.pioneer.co.jp
> *
>
>
> Hi Bill,
>
> I might misunderstand this item.
> Bill, let me know when did you add this sentence in MMC?
> Could you tell me the file name of the MMC meeting minutes?
>
> Best regards,
>
> Keiji Katata
> PIONEER CORP.
>
>
>
>
>
> Bill McFerrin <billmc37 at ctesc.net>@avc-pioneer.com on 2009/04/08 04:14:53
>
> 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 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
> $B7oL>(B:  Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Bill McFerrin <billmc37 at ctesc.net>
> *
> Hi,
> Your are right: The response is incorrect. Fuji agrees.
>
> The more accurate wording you suggested ($B!H(BIf no event /of the
requested
> notification class/ has occurred, $B!D!I(B) is a good thing. It might be
> useful to add a "for example".
>
> Cheers,
> Bill
>
> David Burg wrote:
>   
>> Hello,
>>
>> During our testing of Windows 7, our engineers noticed a difference in
>> the devices$B!G(B implementation of GESN command response to say the
same
>> $B!F(Bno event$B!G(B answer. Below is a capture of an 8 bytes answer
|from one
>> device and of an 4 bytes answer from another device.
>>
>> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
>>
>> We believe this complies to MMC$B!G(Bs:
>>
>> cid:image002.jpg at 01C9AC5C.CBEA04D0
>>
>> (One might want to be careful to clarify $B!H(BIf no event /of the
>> requested notification class/ has occurred, $B!D!I(B because event may
occur
>> in another class and yet can$B!G(Bt be reported.)
>>
>> The other device responds:
>>
>> This does not seem allowed by the current spec, although it is not
>> completely obvious.
>>
>> Also, some software engineers thought they would get NEA = 1b and 4
>> bytes, based on the name of that bit $B!H(BNot Event Available$B!I(B.
>From an
>> English language point of view, there is indeed no event available.
>> However, the spec definition of the bit then contradicts with what one
>> would expect out of English language alone:
>>
>> $B!H(BIf NEA (No Event Available) is set to one, the Drive supports none
of
>> the requested notification classes. If NEA
>>
>> is set to zero, at least one of the requested notification classes is
>> supported.$B!I(B
>>
>> This sounds more like $B!H(BNo Requested Class Supported$B!I(B.
>>
>> So, Microsoft believes this GESN section should be reviewed in detail
>> and clarified.
>>
>> With regards,
>>
>> David.
>>
>>     
> *
> * 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 Apr 13 08:45:07 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 13 Apr 2009 09:45:07 -0600
Subject: May T10 meeting hotel cutoff date is today
Message-ID: <mailman.234.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The cutoff date for the May T10 hotel is today, April 13, 2009. Please make
your hotel reservations ASAP:
  http://www.t10.org/ftp/t10/announce/ann-m091.pdf
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From curtis.ballard at hp.com  Mon Apr 13 16:19:31 2009
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Mon, 13 Apr 2009 23:19:31 +0000
Subject: 2nd notice SMC-3 Working Group conference call 15 April, 8:00-10:00
 AM PST
Message-ID: <mailman.235.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
The original notice didn't include an end time for this call.  This
teleconference is scheduled for 2 hours.
Hewlett Packard will host a teleconference for the SMC-3 working group on
Wednesday, 15 April.  Contact details for that meeting follow.	Please
contact me for access numbers from any countries not listed.
The agenda is available at: http://www.t10.org/ftp/t10/smc-agnd.htm
and is posted in the following document:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-139r0.pdf
Curtis Ballard
Hewlett Packard
-----------------------------------------
Conference Call Passcode:	8983013
Conference Call Access Numbers:
U.S. (toll) dial-in number	281.964.1607
U.S. toll-free dial-in number	877.675.4345
Germany 			069-22-221-6176 or 800-664-7543
Netherlands - Amsterdam 	020-714-3562 or 0800-023-5079
Norway - Oslo			21-033-192 or 800-18-430
United Kingdom			0844-579-0686 or 0808-238-0672
Virtual Rooms Link:
https://www.rooms.hp.com/attend/default.aspx?key=EH57CE6NLK 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From ai.takaharu at jp.panasonic.com  Mon Apr 13 20:56:36 2009
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Tue, 14 Apr 2009 12:56:36 +0900
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.236.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Bill, David,
I missed that sentence in the original David's message, but I think the
wording is not correct. As I explained, the existence of an event for a
Class does not affect to the NEA bit setting. NEA just indicate whether
or not the drive supports the requested event.
For example, if a drive supports Oprational Change, Power, Media and
Device Busy event Classes, and the host requests External Request only,
then the drive returns only the 4-byte Event header with NEA=1, even if
the drive has an Event for a supported Class. Another example is if the
host requests Operational Change Class and the drive does not have any
Event for that Class, the drive must report Event Header with NEA=0,
Notification Class=001b and Operational Change Class Event Descriptor
with Operational Event=0h.
So, the sentence should be "Regardless of the existence of an Event, if
none of the requested noticiation Class is supported, ..."
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: Bill McFerrin <billmc37 at ctesc.net>
>To: keiji_katata at post.pioneer.co.jp
>Cc: mtfuji5 at avc-pioneer.com, T10 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
>Date: Mon, 13 Apr 2009 10:54:25 -0500
>Subject: Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
>
> Hi
> The sentence: "If no event / of the requested notification class / has
> occurred, ..." was David Burg's attempt to be clear about what he
> believes to be the meaning of the text. It is not in any version of MMC.
> Since some people are confused, clarification is needed. It appears that
> David's proposed sentence is correct.
> 
> Cheers,
> Bill McFerrin
> 
> 
> keiji_katata at post.pioneer.co.jp wrote:
> > * From the T10 Reflector (t10 at t10.org), posted by:
> > * keiji_katata at post.pioneer.co.jp
> > *
> >
> >
> > Hi Bill,
> >
> > I might misunderstand this item.
> > Bill, let me know when did you add this sentence in MMC?
> > Could you tell me the file name of the MMC meeting minutes?
> >
> > Best regards,
> >
> > Keiji Katata
> > PIONEER CORP.
> >
> >
> >
> >
> >
> > Bill McFerrin <billmc37 at ctesc.net>@avc-pioneer.com on 2009/04/08 04:14:53
> >
> > 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 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
> > $B7oL>(B:  Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of
'No Event'
> >
> > * From the T10 Reflector (t10 at t10.org), posted by:
> > * Bill McFerrin <billmc37 at ctesc.net>
> > *
> > Hi,
> > Your are right: The response is incorrect. Fuji agrees.
> >
> > The more accurate wording you suggested ($B!H(BIf no event /of the
requested
> > notification class/ has occurred, $B!D!I(B) is a good thing. It might
be
> > useful to add a "for example".
> >
> > Cheers,
> > Bill
> >
> > David Burg wrote:
> >   
> >> Hello,
> >>
> >> During our testing of Windows 7, our engineers noticed a difference in
> >> the devices$B!G(B implementation of GESN command response to say the
same
> >> $B!F(Bno event$B!G(B answer. Below is a capture of an 8 bytes answer
|from one
> >> device and of an 4 bytes answer from another device.
> >>
> >> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
> >>
> >> We believe this complies to MMC$B!G(Bs:
> >>
> >> cid:image002.jpg at 01C9AC5C.CBEA04D0
> >>
> >> (One might want to be careful to clarify $B!H(BIf no event /of the
> >> requested notification class/ has occurred, $B!D!I(B because event may
occur
> >> in another class and yet can$B!G(Bt be reported.)
> >>
> >> The other device responds:
> >>
> >> This does not seem allowed by the current spec, although it is not
> >> completely obvious.
> >>
> >> Also, some software engineers thought they would get NEA = 1b and 4
> >> bytes, based on the name of that bit $B!H(BNot Event
Available$B!I(B. >From an
> >> English language point of view, there is indeed no event available.
> >> However, the spec definition of the bit then contradicts with what one
> >> would expect out of English language alone:
> >>
> >> $B!H(BIf NEA (No Event Available) is set to one, the Drive supports
none of
> >> the requested notification classes. If NEA
> >>
> >> is set to zero, at least one of the requested notification classes is
> >> supported.$B!I(B
> >>
> >> This sounds more like $B!H(BNo Requested Class Supported$B!I(B.
> >>
> >> So, Microsoft believes this GESN section should be reviewed in detail
> >> and clarified.
> >>
> >> With regards,
> >>
> >> David.
> >>
> >>	 
> > *
> > * 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
> >
> >   
----------------- End of the original message -----------------
*
* 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 Apr 14 09:02:04 2009
From: lohmeyer at t10.org (John Lohmeyer)
Date: Tue, 14 Apr 2009 10:02:04 -0600
Subject: Fwd: Final Follow-Up to INCITS 3022 - Appointment of Chairman
  - INCITS/T10, SCSI Storage Interfaces
Message-ID: <mailman.237.1441607349.22516.t10@sandbox.t10.org>

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

>From: "Garner, Jennifer" <jgarner at itic.org>
>To: "Lohmeyer, John" <lohmeyer at t10.org>
>CC: "Robinson, Gary" <g.robinson at computer.org>, "eb at standards.incits.org"
>	 <eb at standards.incits.org>
>Date: Tue, 14 Apr 2009 09:52:16 -0600
>Subject: Final Follow-Up to INCITS 3022 - Appointment of Chairman -
> INCITS/T10, SCSI Storage Interfaces
>  
>eb-2009-00624 
>INCITS 
>InterNational Committee for Information Technology Standards 
>INCITS Secretariat, Information Technology Industry Council (ITI) 
>1250 Eye St. NW, Suite 200, Washington, DC 20005 
>Telephone 202-737-8888; Fax 202-638-4922 
>
>----------
>
>
>Date: April 14, 2009 
>Reference Document: INCITS 3022
>Reply to: Jennifer T. Garner 
>Phone: 202-626-5737 
>Email: jgarner at itic.org 
>cc:   John Lohmeyer, INCITS/T10 Chairman 
>	 Gary Robinson, INCITS/T10 International Representative
>
>----------
> 
> 
>To:
>INCITS Executive Board Members 
>INCITS/T10 Members
>Subject:
>Final Follow-Up to INCITS 3022 - Appointment of Chairman - INCITS/T10, SCSI
Storage Interfaces
>
>
>INCITS 3022 - Appointment of Chairman - INCITS/T10, SCSI Storage Interfaces,
closed on April 12, 2009.  Mr. John Lohmeyer received the required level of
support (majority) to secure appointment as Chairman of INCITS/T10, SCSI
Storage Interfaces.  His second term begins in July 2009 and will expire in
July 2012. 
>As required by INCITS procedures, an appointed INCITS Subgroup officer must
attend INCITS Subgroup Officer Training within one year of their appointment.
 As Mr. Lohmeyer last received training on July 18, 2006, he must receive
INCITS Subgroup Officer Training for Chairmen within one year of his most
recent appointment  - no later than July 2010. 
> 
>
>Jennifer T. Garner
>Director, Standards Programs
>INCITS/Information Technology Industry Council
>1250 Eye Street, NW - Suite 200
>Washington, DC 20005
>202.626.5737
>e-mail:   jgarner at itic.org
>website:
<www.in">http://mail.itic.org/exchweb/bin/redir.asp?URL=http://www.incits.org/>www.in
cits.org
> 
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907


From curtis.stevens at wdc.com  Tue Apr 14 14:47:45 2009
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Tue, 14 Apr 2009 14:47:45 -0700
Subject: SAT-2
Message-ID: <mailman.238.1441607349.22516.t10@sandbox.t10.org>

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

When: Thursday, April 23, 2009 10:00 AM-12:00 PM (GMT-08:00) Pacific Time
(US & Canada).
Where: WebEx
*~*~*~*~*~*~*~*~*~*
Curtis Stevens invites you to an online meeting using WebEx.
Meeting Number: 574 025 511
Meeting Password: SAT2FinalReview
-------------------------------------------------------
To join this meeting
-------------------------------------------------------
1. Go to https://wdc007.webex.com/wdc007/j.php?J=574025511
2. Enter the meeting password: SAT2FinalReview
3. Click "Join Now".
4. Follow the instructions that appear on your screen to join the
teleconference.
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio
and any documents and other materials exchanged or viewed during the session
to be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, do not join the session.
-------------------------------------------------------
To only join the teleconference
-------------------------------------------------------
Call-in toll number (US/Canada): 1-408-792-6300 
http://www.webex.com 
We've got to start meeting like this(TM)


From George.Penokie at lsi.com  Tue Apr 14 15:59:12 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 14 Apr 2009 15:59:12 -0700
Subject: SAM ACA question
Message-ID: <mailman.239.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Penokie, George" <George.Penokie at lsi.com>
*
Fred,
The answer to your question is FUNCTION REJECTED and FUNCTION REJECTED. 
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight,
Frederick
Sent: Thursday, April 09, 2009 11:08 AM
To: t10 at t10.org
Subject: SAM ACA question
* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
SAM5r01 clause 7.4 Clear ACA contains the following statement:
"The service response for a CLEAR ACA request received from an I_T nexus
other than the faulted I_T nexus shall be FUNCTION REJECTED."
That statement seems to assume there is an ACA Active (a faulted I_T nexus
exists somewhere) - "other than THE faulted I_T nexus..."
If there is no faulted I_T nexus anywhere (ACA is not active), then will a
CLEAR ACA TMF still respond with FUNCTION REJECTED? or does it act like ABORT
TASK when the task is not in the task set and respond with FUNCTION COMPLETE
(since ACA is in fact cleared)?
host puts 2 commands "on the wire"
the first one gets CHECK CONDITION
the second one gets ACA ACTIVE
the target has a hard reset occur
host sends CLEAR ACA - what is the response?
	Fred Knight
*
* 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 Frederick.Knight at netapp.com  Tue Apr 14 16:02:51 2009
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Tue, 14 Apr 2009 19:02:51 -0400
Subject: Thin Provisioning Conference-Call
Message-ID: <mailman.240.1441607349.22516.t10@sandbox.t10.org>

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

The Next Scheduled Thin Provisioning Con-Call has been set up as
follows:
frederick knight has invited you to join a meeting on the Web, using
WebEx 
Topic: Thin Provisioning 
Date: Wednesday, April 22, 2009 
Time: 12:00 pm, Pacific Daylight Time (GMT -07:00, San Francisco) 
Meeting number: 929 474 703 
Meeting password: TP 
Please click the link below to see more information, or to join the
meeting. 
NOTE: You do not need to register for a WebEx Account to attend this
meeting. Just click on the link below and use the Meeting password: TP 
https://netapp-meeting.webex.com/netapp-meeting/j.php?ED=116819362&UID=0
&PW=64486764
<https://netapp-meeting.webex.com/netapp-meeting/j.php?ED=116819362&UID=
0&PW=64486764>	
Teleconference: 1-888-765-3653 
ID - 595-2226# 
To contact frederick knight, 
send a message to this address: knight at netapp.com
  


From George.Penokie at lsi.com  Tue Apr 14 16:44:53 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Tue, 14 Apr 2009 16:44:53 -0700
Subject: SPL disparity errors counter conflict
Message-ID: <mailman.241.1441607349.22516.t10@sandbox.t10.org>

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

The running disparity errors counter in SPL (and SAS-2) in two places is
called out as a saturating counter and one place as a wrapping counter. (see
below for the wording) Note that WC stands for wrapping counter.
So which is it. It appears that the specification in table 37 (SPL r1) is not
correct, any comments.
4.11 Phy events
Phys shall count the following events using saturating counters and report
them in the Protocol-Specific Port log page (see 9.2.8.1) and/or the SMP
REPORT PHY ERROR LOG function (see 9.4.3.11):
a) invalid dwords received;
b) dwords received with running disparity errors;
c) loss of dword synchronization; and
d) phy reset problems.
Table 37 - PHY EVENT SOURCE field (part 1 of 4)
02h Running disparity error count	     WC        Number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences
9.4.3.11 REPORT PHY ERROR LOG function
The RUNNING DISPARITY ERROR COUNT field indicates the number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences. The count shall stop at the maximum value.
The RUNNING DISPARITY ERROR COUNT field is set to a vendor-specific value
after power on.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com


From Elliott at hp.com  Tue Apr 14 18:31:49 2009
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 15 Apr 2009 01:31:49 +0000
Subject: SPL disparity errors counter conflict
Message-ID: <mailman.242.1441607349.22516.t10@sandbox.t10.org>

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

Both.
When reported via the old REPORT PHY ERROR LOG function, they are always
saturating values.  They can be cleared with the PHY CONTROL function CLEAR
ERROR LOG phy operation, but that's not multi-initiator friendly.
When reported via the REPORT PHY EVENT LIST function (if those events have
been selected as sources - there are many other sources also available), they
are wrapping values.  These are multi-initiator friendly.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Tuesday, April 14, 2009 6:45 PM
To: t10 at t10.org
Subject: SPL disparity errors counter conflict
The running disparity errors counter in SPL (and SAS-2) in two places is
called out as a saturating counter and one place as a wrapping counter. (see
below for the wording) Note that WC stands for wrapping counter.
So which is it. It appears that the specification in table 37 (SPL r1) is not
correct, any comments.
4.11 Phy events
Phys shall count the following events using saturating counters and report
them in the Protocol-Specific Port log page (see 9.2.8.1) and/or the SMP
REPORT PHY ERROR LOG function (see 9.4.3.11):
a) invalid dwords received;
b) dwords received with running disparity errors;
c) loss of dword synchronization; and
d) phy reset problems.
Table 37 - PHY EVENT SOURCE field (part 1 of 4)
02h Running disparity error count	     WC        Number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences
9.4.3.11 REPORT PHY ERROR LOG function
The RUNNING DISPARITY ERROR COUNT field indicates the number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences. The count shall stop at the maximum value.
The RUNNING DISPARITY ERROR COUNT field is set to a vendor-specific value
after power on.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com


From George.Penokie at lsi.com  Wed Apr 15 09:03:01 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Wed, 15 Apr 2009 10:03:01 -0600
Subject: Error in new power conditions model section
Message-ID: <mailman.243.1441607349.22516.t10@sandbox.t10.org>

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

The following new wording added to section 5.10.1 Power conditions overview
is not correct:
If any power condition timer in the Power Condition mode page is enabled,
then that timer shall be stopped on receipt of a command. On completion of
the command, all enabled timers shall be reinitialized based on their Power
Condition mode page values and then started.
That wording conflicts with the following wording in section 6.29 REQUEST
SENSE command:
Upon completion of the REQUEST SENSE command, the logical unit shall return
to the same power condition that was active before the REQUEST SENSE command
was received. A REQUEST SENSE command shall not reset any power condition
timers.
The wording that should have been put into section 5.10.1 Power condition
overview should have been:
If any power condition timer in the Power Condition mode page is enabled,
then that timer shall be stopped on receipt of a command. On completion of
the command, except the REQUEST SENSE command  (see 6.29), all enabled timers
shall be reinitialized based on their Power Condition mode page values and
then started.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com


From Kevin_Marks at Dell.com  Wed Apr 15 11:18:32 2009
From: Kevin_Marks at Dell.com (Kevin_Marks at Dell.com)
Date: Wed, 15 Apr 2009 13:18:32 -0500
Subject: Error in new power conditions model section
Message-ID: <mailman.244.1441607349.22516.t10@sandbox.t10.org>

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

I believe your text is still incorrect, as it is unclear whether the
"expect the REQUEST SENSE command" applies to both reinitialized and
start or just reinitialized.  My reading would say both, which is not
correct. 
If any power condition timer in the Power Condition mode page is
enabled, then that timer shall be stopped on receipt of a command. On
completion of the command:
1)     if the command was not a REQUEST SENSE command (see 6.29) then,
all enabled timers shall be reinitialized based on their Power Condition
mode page values ; and 
2)     all enabled timers shall be started.
Kevin
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Wednesday, April 15, 2009 11:03 AM
To: t10 at t10.org
Subject: Error in new power conditions model section
The following new wording added to section 5.10.1 Power conditions
overview is not correct:
If any power condition timer in the Power Condition mode page is
enabled, then that timer shall be stopped on receipt of a command. On
completion of the command, all enabled timers shall be reinitialized
based on their Power Condition mode page values and then started.
That wording conflicts with the following wording in section 6.29
REQUEST SENSE command:
Upon completion of the REQUEST SENSE command, the logical unit shall
return to the same power condition that was active before the REQUEST
SENSE command was received. A REQUEST SENSE command shall not reset any
power condition timers.
The wording that should have been put into section 5.10.1 Power
condition overview should have been:
If any power condition timer in the Power Condition mode page is
enabled, then that timer shall be stopped on receipt of a command. On
completion of the command, except the REQUEST SENSE command  (see 6.29),
all enabled timers shall be reinitialized based on their Power Condition
mode page values and then started.
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com


From roweber at ieee.org  Wed Apr 15 12:58:03 2009
From: roweber at ieee.org (Ralph Weber)
Date: Wed, 15 Apr 2009 14:58:03 -0500
Subject: Error in new power conditions model section
Message-ID: <mailman.245.1441607349.22516.t10@sandbox.t10.org>

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

Under these circumstances, I do not feel comfortable making
the change as an editorial correction.
All the best,
.Ralph
Kevin_Marks at Dell.com wrote:
>
> I believe your text is still incorrect, as it is unclear whether the 
> "expect the REQUEST SENSE command" applies to both reinitialized and 
> start or just reinitialized.	My reading would say both, which is not 
> correct.
>
>  
>
> If any power condition timer in the Power Condition mode page is 
> enabled, then that timer shall be stopped on receipt of a command. On 
> completion of the command:
>
> 1)	 if the command was not a REQUEST SENSE command (see 6.29) then, 
>  all enabled timers shall be reinitialized based on their Power 
> Condition mode page values ; and
>
> 2)	 all enabled timers shall be started.
>
>  
>
> Kevin
>
>  
>
>  
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of 
> *Penokie, George
> *Sent:* Wednesday, April 15, 2009 11:03 AM
> *To:* t10 at t10.org
> *Subject:* Error in new power conditions model section
>
>  
>
>  
>
> The following new wording added to section 5.10.1 Power conditions 
> overview is not correct:
>
>  
>
> If any power condition timer in the Power Condition mode page is 
> enabled, then that timer shall be stopped on receipt of a command. On 
> completion of the command, all enabled timers shall be reinitialized 
> based on their Power Condition mode page values and then started.
>
>  
>
> That wording conflicts with the following wording in section 6.29 
> REQUEST SENSE command:
>
>  
>
> Upon completion of the REQUEST SENSE command, the logical unit shall 
> return to the same power condition that was active before the REQUEST 
> SENSE command was received. A REQUEST SENSE command shall not reset 
> any power condition timers.
>
>  
>
> The wording that should have been put into section 5.10.1 Power 
> condition overview should have been:
>
>  
>
> If any power condition timer in the Power Condition mode page is 
> enabled, then that timer shall be stopped on receipt of a command. On 
> completion of the command, except the REQUEST SENSE command  (see 
> 6.29), all enabled timers shall be reinitialized based on their Power 
> Condition mode page values and then started.
>
>  
>
>  
>
> Bye for now,
>
> George Penokie
>
>  
>
> LSI Corporation
>
> 3033 41st St. NW
>
> Suite 100
>
> Rochester, MN 55901
>
>  
>
> 507-328-9017
>
> george.penokie at lsi.com
>
>  
>
>  
>
>  
>


From Kevin_Marks at Dell.com  Wed Apr 15 14:35:05 2009
From: Kevin_Marks at Dell.com (Kevin_Marks at Dell.com)
Date: Wed, 15 Apr 2009 16:35:05 -0500
Subject: Error in new power conditions model section
Message-ID: <mailman.246.1441607349.22516.t10@sandbox.t10.org>

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

I have already included them in my proposal.
Kevin
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph
Weber
Sent: Wednesday, April 15, 2009 2:58 PM
To: t10 at t10.org
Subject: Re: Error in new power conditions model section
Under these circumstances, I do not feel comfortable making 
the change as an editorial correction.
All the best,
.Ralph
Kevin_Marks at Dell.com wrote: 
I believe your text is still incorrect, as it is unclear whether the
"expect the REQUEST SENSE command" applies to both reinitialized and
start or just reinitialized.  My reading would say both, which is not
correct. 
If any power condition timer in the Power Condition mode page is
enabled, then that timer shall be stopped on receipt of a command. On
completion of the command:
if the command was not a REQUEST SENSE command (see 6.29) then,  all
enabled timers shall be reinitialized based on their Power Condition
mode page values ; and 
all enabled timers shall be started.
Kevin
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Wednesday, April 15, 2009 11:03 AM
To: t10 at t10.org
Subject: Error in new power conditions model section
The following new wording added to section 5.10.1 Power conditions
overview is not correct:
If any power condition timer in the Power Condition mode page is
enabled, then that timer shall be stopped on receipt of a command. On
completion of the command, all enabled timers shall be reinitialized
based on their Power Condition mode page values and then started.
That wording conflicts with the following wording in section 6.29
REQUEST SENSE command:
Upon completion of the REQUEST SENSE command, the logical unit shall
return to the same power condition that was active before the REQUEST
SENSE command was received. A REQUEST SENSE command shall not reset any
power condition timers.
The wording that should have been put into section 5.10.1 Power
condition overview should have been:
If any power condition timer in the Power Condition mode page is
enabled, then that timer shall be stopped on receipt of a command. On
completion of the command, except the REQUEST SENSE command  (see 6.29),
all enabled timers shall be reinitialized based on their Power Condition
mode page values and then started.
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com


From Paul.Stone at Quantum.Com  Wed Apr 15 16:22:13 2009
From: Paul.Stone at Quantum.Com (Paul Stone)
Date: Wed, 15 Apr 2009 17:22:13 -0600
Subject: ADT-2 Rev 6 is available
Message-ID: <mailman.247.1441607349.22516.t10@sandbox.t10.org>

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

This incorporates Internet ADT (iADT) and SCSI Command Frame IU fixes.
http://www.t10.org/cgi-bin/ac.pl?t=f&f=adt2r06.pdf
___________________________________
Paul Stone | Firmware Engineer | Quantum Corporation | Office:
949.725.1874 | paul.stone at quantum.com  
___________________________________
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individual(s) or organization(s), without restriction.


From Albert.Chen at microsoft.com  Thu Apr 16 13:58:45 2009
From: Albert.Chen at microsoft.com (Albert Chen)
Date: Thu, 16 Apr 2009 13:58:45 -0700
Subject: May T10 meeting hotel cutoff date is today
Message-ID: <mailman.248.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Albert Chen <Albert.Chen at microsoft.com>
*
Hi John and T10,
The cutoff date for Bellevue Hyatt has been extended till April 20, 2009.
Thanks,
Albert
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of John Lohmeyer
Sent: Monday, April 13, 2009 8:45 AM
To: T10 Reflector
Subject: May T10 meeting hotel cutoff date is today
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The cutoff date for the May T10 hotel is today, April 13, 2009. Please make
your hotel reservations ASAP:
  http://www.t10.org/ftp/t10/announce/ann-m091.pdf
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* 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 cachen at microsoft.com  Thu Apr 16 14:05:05 2009
From: cachen at microsoft.com (Calvin Chen)
Date: Thu, 16 Apr 2009 14:05:05 -0700
Subject: May T10 meeting hotel cutoff date extened to April 20, 2009 
Message-ID: <mailman.249.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Calvin Chen <cachen at microsoft.com>
*
With the confirmation from Bob Griswold, the cutoff date for the May T10
hotel has been extended to April 20, 2009. Please make your hotel
reservations ASAP!
Calvin Chen
Microsoft Corporation
425-7077193 
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of John Lohmeyer
Sent: Monday, April 13, 2009 8:45 AM
To: T10 Reflector
Subject: May T10 meeting hotel cutoff date is today
* From the T10 Reflector (t10 at t10.org), posted by:
* John Lohmeyer <lohmeyer at t10.org>
*
The cutoff date for the May T10 hotel is today, April 13, 2009. Please make
your hotel reservations ASAP:
  http://www.t10.org/ftp/t10/announce/ann-m091.pdf
--
John Lohmeyer		       Email: lohmeyer at t10.org
LSI Corp.		       Voice: +1-719-533-7560
4420 ArrowsWest Dr.		Cell: +1-719-338-1642
Colo Spgs, CO 80907
*
* 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 ai.takaharu at jp.panasonic.com  Thu Apr 16 18:14:41 2009
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Fri, 17 Apr 2009 10:14:41 +0900
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.250.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Bill and David,
I am sorry I made a mistake again. 
The suggented text of "If no event / of the requested notification class
/ has occurred, ..." deos not explain the meaning of NEA, so I agree
with your suggention.
My opinion was that we need to cralify the meaning of NEA. I also agree
to;
> > >> This sounds more like $B!H(BNo Requested Class Supported$B!I(B.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: Takaharu Ai <ai.takaharu at jp.panasonic.com>
>To: mtfuji5 at avc-pioneer.com
>Cc: keiji_katata at post.pioneer.co.jp, T10 Reflector <t10 at t10.org>, Ope
Aladekomo <Ope.Aladekomo at microsoft.com>
>Date: Tue, 14 Apr 2009 12:56:36 +0900
>Subject: Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
>
> Hello Bill, David,
> 
> I missed that sentence in the original David's message, but I think the
> wording is not correct. As I explained, the existence of an event for a
> Class does not affect to the NEA bit setting. NEA just indicate whether
> or not the drive supports the requested event.
> 
> For example, if a drive supports Oprational Change, Power, Media and
> Device Busy event Classes, and the host requests External Request only,
> then the drive returns only the 4-byte Event header with NEA=1, even if
> the drive has an Event for a supported Class. Another example is if the
> host requests Operational Change Class and the drive does not have any
> Event for that Class, the drive must report Event Header with NEA=0,
> Notification Class=001b and Operational Change Class Event Descriptor
> with Operational Event=0h.
> 
> 
> So, the sentence should be "Regardless of the existence of an Event, if
> none of the requested noticiation Class is supported, ..."
> 
> 
> Best Regards,
> 
> Harry Ai
> VEBU,
> AVC Networks Company,
> Panasonic Corporation
> Osaka, Japan
> 
> 
> ---------------- Start of the original message ----------------
> >From: Bill McFerrin <billmc37 at ctesc.net>
> >To: keiji_katata at post.pioneer.co.jp
> >Cc: mtfuji5 at avc-pioneer.com, T10 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
> >Date: Mon, 13 Apr 2009 10:54:25 -0500
> >Subject: Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
> >
> > Hi
> > The sentence: "If no event / of the requested notification class / has
> > occurred, ..." was David Burg's attempt to be clear about what he
> > believes to be the meaning of the text. It is not in any version of MMC.
> > Since some people are confused, clarification is needed. It appears that
> > David's proposed sentence is correct.
> > 
> > Cheers,
> > Bill McFerrin
> > 
> > 
> > keiji_katata at post.pioneer.co.jp wrote:
> > > * From the T10 Reflector (t10 at t10.org), posted by:
> > > * keiji_katata at post.pioneer.co.jp
> > > *
> > >
> > >
> > > Hi Bill,
> > >
> > > I might misunderstand this item.
> > > Bill, let me know when did you add this sentence in MMC?
> > > Could you tell me the file name of the MMC meeting minutes?
> > >
> > > Best regards,
> > >
> > > Keiji Katata
> > > PIONEER CORP.
> > >
> > >
> > >
> > >
> > >
> > > Bill McFerrin <billmc37 at ctesc.net>@avc-pioneer.com on 2009/04/08
04:14:53
> > >
> > > 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 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
> > > $B7oL>(B:  Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of
'No Event'
> > >
> > > * From the T10 Reflector (t10 at t10.org), posted by:
> > > * Bill McFerrin <billmc37 at ctesc.net>
> > > *
> > > Hi,
> > > Your are right: The response is incorrect. Fuji agrees.
> > >
> > > The more accurate wording you suggested ($B!H(BIf no event /of the
requested
> > > notification class/ has occurred, $B!D!I(B) is a good thing. It might
be
> > > useful to add a "for example".
> > >
> > > Cheers,
> > > Bill
> > >
> > > David Burg wrote:
> > >	
> > >> Hello,
> > >>
> > >> During our testing of Windows 7, our engineers noticed a difference in
> > >> the devices$B!G(B implementation of GESN command response to say the
same
> > >> $B!F(Bno event$B!G(B answer. Below is a capture of an 8 bytes
answer from one
> > >> device and of an 4 bytes answer from another device.
> > >>
> > >> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
> > >>
> > >> We believe this complies to MMC$B!G(Bs:
> > >>
> > >> cid:image002.jpg at 01C9AC5C.CBEA04D0
> > >>
> > >> (One might want to be careful to clarify $B!H(BIf no event /of the
> > >> requested notification class/ has occurred, $B!D!I(B because event
may occur
> > >> in another class and yet can$B!G(Bt be reported.)
> > >>
> > >> The other device responds:
> > >>
> > >> This does not seem allowed by the current spec, although it is not
> > >> completely obvious.
> > >>
> > >> Also, some software engineers thought they would get NEA = 1b and 4
> > >> bytes, based on the name of that bit $B!H(BNot Event
Available$B!I(B. >From an
> > >> English language point of view, there is indeed no event available.
> > >> However, the spec definition of the bit then contradicts with what one
> > >> would expect out of English language alone:
> > >>
> > >> $B!H(BIf NEA (No Event Available) is set to one, the Drive supports
none of
> > >> the requested notification classes. If NEA
> > >>
> > >> is set to zero, at least one of the requested notification classes is
> > >> supported.$B!I(B
> > >>
> > >> This sounds more like $B!H(BNo Requested Class Supported$B!I(B.
> > >>
> > >> So, Microsoft believes this GESN section should be reviewed in detail
> > >> and clarified.
> > >>
> > >> With regards,
> > >>
> > >> David.
> > >>
> > >>	   
> > > *
> > > * 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
> > >
> > >	
> 
> ----------------- End of the original message -----------------
> 
> 
----------------- End of the original message -----------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From ai.takaharu at jp.panasonic.com  Thu Apr 16 18:14:41 2009
From: ai.takaharu at jp.panasonic.com (Takaharu Ai)
Date: Fri, 17 Apr 2009 10:14:41 +0900
Subject: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No Event'
Message-ID: <mailman.251.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
* From the T10 Reflector (t10 at t10.org), posted by:
* Takaharu Ai <ai.takaharu at jp.panasonic.com>
*
Hello Bill and David,
I am sorry I made a mistake again. 
The suggented text of "If no event / of the requested notification class
/ has occurred, ..." deos not explain the meaning of NEA, so I agree
with your suggention.
My opinion was that we need to cralify the meaning of NEA. I also agree
to;
> > >> This sounds more like $B!H(BNo Requested Class Supported$B!I(B.
Best Regards,
Harry Ai
VEBU,
AVC Networks Company,
Panasonic Corporation
Osaka, Japan
---------------- Start of the original message ----------------
>From: Takaharu Ai <ai.takaharu at jp.panasonic.com>
>To: mtfuji5 at avc-pioneer.com
>Cc: keiji_katata at post.pioneer.co.jp, T10 Reflector <t10 at t10.org>, Ope
Aladekomo <Ope.Aladekomo at microsoft.com>
>Date: Tue, 14 Apr 2009 12:56:36 +0900
>Subject: Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
>
> Hello Bill, David,
> 
> I missed that sentence in the original David's message, but I think the
> wording is not correct. As I explained, the existence of an event for a
> Class does not affect to the NEA bit setting. NEA just indicate whether
> or not the drive supports the requested event.
> 
> For example, if a drive supports Oprational Change, Power, Media and
> Device Busy event Classes, and the host requests External Request only,
> then the drive returns only the 4-byte Event header with NEA=1, even if
> the drive has an Event for a supported Class. Another example is if the
> host requests Operational Change Class and the drive does not have any
> Event for that Class, the drive must report Event Header with NEA=0,
> Notification Class=001b and Operational Change Class Event Descriptor
> with Operational Event=0h.
> 
> 
> So, the sentence should be "Regardless of the existence of an Event, if
> none of the requested noticiation Class is supported, ..."
> 
> 
> Best Regards,
> 
> Harry Ai
> VEBU,
> AVC Networks Company,
> Panasonic Corporation
> Osaka, Japan
> 
> 
> ---------------- Start of the original message ----------------
> >From: Bill McFerrin <billmc37 at ctesc.net>
> >To: keiji_katata at post.pioneer.co.jp
> >Cc: mtfuji5 at avc-pioneer.com, T10 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
> >Date: Mon, 13 Apr 2009 10:54:25 -0500
> >Subject: Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of 'No
Event'
> >
> > Hi
> > The sentence: "If no event / of the requested notification class / has
> > occurred, ..." was David Burg's attempt to be clear about what he
> > believes to be the meaning of the text. It is not in any version of MMC.
> > Since some people are confused, clarification is needed. It appears that
> > David's proposed sentence is correct.
> > 
> > Cheers,
> > Bill McFerrin
> > 
> > 
> > keiji_katata at post.pioneer.co.jp wrote:
> > > * From the T10 Reflector (t10 at t10.org), posted by:
> > > * keiji_katata at post.pioneer.co.jp
> > > *
> > >
> > >
> > > Hi Bill,
> > >
> > > I might misunderstand this item.
> > > Bill, let me know when did you add this sentence in MMC?
> > > Could you tell me the file name of the MMC meeting minutes?
> > >
> > > Best regards,
> > >
> > > Keiji Katata
> > > PIONEER CORP.
> > >
> > >
> > >
> > >
> > >
> > > Bill McFerrin <billmc37 at ctesc.net>@avc-pioneer.com on 2009/04/08
04:14:53
> > >
> > > 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 Reflector <t10 at t10.org>, Ope Aladekomo
<Ope.Aladekomo at microsoft.com>
> > > $B7oL>(B:  Re: [MtFuji] MMC / Mt Fuji: 8 bytes and 4 bytes flavors of
'No Event'
> > >
> > > * From the T10 Reflector (t10 at t10.org), posted by:
> > > * Bill McFerrin <billmc37 at ctesc.net>
> > > *
> > > Hi,
> > > Your are right: The response is incorrect. Fuji agrees.
> > >
> > > The more accurate wording you suggested ($B!H(BIf no event /of the
requested
> > > notification class/ has occurred, $B!D!I(B) is a good thing. It might
be
> > > useful to add a "for example".
> > >
> > > Cheers,
> > > Bill
> > >
> > > David Burg wrote:
> > >	
> > >> Hello,
> > >>
> > >> During our testing of Windows 7, our engineers noticed a difference in
> > >> the devices$B!G(B implementation of GESN command response to say the
same
> > >> $B!F(Bno event$B!G(B answer. Below is a capture of an 8 bytes
answer from one
> > >> device and of an 4 bytes answer from another device.
> > >>
> > >> (Note that BusTrace incorrectly interpreted the Polled bit as Immed.)
> > >>
> > >> We believe this complies to MMC$B!G(Bs:
> > >>
> > >> cid:image002.jpg at 01C9AC5C.CBEA04D0
> > >>
> > >> (One might want to be careful to clarify $B!H(BIf no event /of the
> > >> requested notification class/ has occurred, $B!D!I(B because event
may occur
> > >> in another class and yet can$B!G(Bt be reported.)
> > >>
> > >> The other device responds:
> > >>
> > >> This does not seem allowed by the current spec, although it is not
> > >> completely obvious.
> > >>
> > >> Also, some software engineers thought they would get NEA = 1b and 4
> > >> bytes, based on the name of that bit $B!H(BNot Event
Available$B!I(B. >From an
> > >> English language point of view, there is indeed no event available.
> > >> However, the spec definition of the bit then contradicts with what one
> > >> would expect out of English language alone:
> > >>
> > >> $B!H(BIf NEA (No Event Available) is set to one, the Drive supports
none of
> > >> the requested notification classes. If NEA
> > >>
> > >> is set to zero, at least one of the requested notification classes is
> > >> supported.$B!I(B
> > >>
> > >> This sounds more like $B!H(BNo Requested Class Supported$B!I(B.
> > >>
> > >> So, Microsoft believes this GESN section should be reviewed in detail
> > >> and clarified.
> > >>
> > >> With regards,
> > >>
> > >> David.
> > >>
> > >>	   
> > > *
> > > * 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
> > >
> > >	
> 
> ----------------- End of the original message -----------------
> 
> 
----------------- End of the original message -----------------
*
* 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 Apr 18 23:01:20 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 19 Apr 2009 00:01:20 -0600
Subject: Recent T10 documents uploaded since 2009/04/12
Message-ID: <mailman.252.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SMC-3 Use of LOGICAL UNIT COMMUNICATION FAILURE
(by: Rod Wideman)
T10/08-271r3   Uploaded: 2009/04/15   20840 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-271r3.pdf
SPC-4 SBC-3 Add disable protection information check on verify feature
(by: Gerald Houlder)
T10/09-134r0   Uploaded: 2009/04/17   154409 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-134r0.pdf
SAT-3 Translation of idle and standby power condition commands
(by: Gerald Houlder)
T10/09-141r0   Uploaded: 2009/04/17   34235 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-141r0.pdf
Molex Internal Mini SAS HD - 03/17/09 Presentation
(by: Jay Neer)
T10/09-143r0   Uploaded: 2009/04/13   921882 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-143r0.pdf
Molex External Mini SAS HD - 03/17/2009 Presentation
(by: Jay Neer)
T10/09-144r0   Uploaded: 2009/04/13   1590032 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-144r0.pdf
SPL: Fix SMP Phy Control Function Result for an invalid Phy Operation
(by: Brad Besmer)
T10/09-145r0   Uploaded: 2009/04/14   11466 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-145r0.pdf
SSC-4: Tape end-to-end logical block protection (Proposal)
(by: Kevin Butt)
T10/09-146r0   Uploaded: 2009/04/15   193099 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-146r0.pdf
SAT-2 Update Translation of ATA errors to SCSI errors for ATA8-ACS
(by: Brad Besmer)
T10/09-147r0   Uploaded: 2009/04/14   13762 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-147r0.pdf
Minutes SMC-3 15April2009 Phone Conference
(by: Kevin Butt)
T10/09-148r0   Uploaded: 2009/04/15   46655 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-148r0.pdf
Minutes: ADI Teleconference meeting notes for 1 April, 2009
(by: Curtis Ballard)
T10/09-149r0   Uploaded: 2009/04/15   20017 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-149r0.pdf
Minutes: ADI Teleconference meeting notes for 1 April, 2009
(by: Curtis Ballard)
T10/09-149r1   Uploaded: 2009/04/17   20242 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-149r1.pdf
SAS-2 Changes from sas2r15a to sas2r16
(by: Rob Elliott)
T10/09-151r0   Uploaded: 2009/04/18   9301 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-151r0.pdf
Working Drafts
--------------
Automation/Drive Interface - Transport Protocol - 2 ADT-2)
(Editor: Paul Stone)
 Rev: 06       Uploaded: 2009/04/14   1463423 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=adt2r06.pdf
MultiMedia Command Set - 6 (MMC-6)
(Editor: Bill McFerrin)
 Rev: 02c      Uploaded: 2009/04/15   4189445 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc6r02c.pdf
Serial Attached SCSI - 2 (SAS-2)
(Editor: Rob Elliott)
 Rev: 16       Uploaded: 2009/04/18   7404699 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sas2r16.pdf
Serial Attached SCSI - 2 (SAS-2)
(Editor: Rob Elliott)
 Rev: 16       Uploaded: 2009/04/18   3269566 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=sas2r16.zip
(Report generated on 2009/04/19 at 00:01:20)
*
* 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 Apr 20 03:00:28 2009
From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp)
Date: Mon, 20 Apr 2009 19:00:28 +0900
Subject: Posted: April Meeting minutes and other documents
Message-ID: <mailman.253.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hello all,
I posted meeting minutes and other documents including action items on ftp.
<ftp.avc-pioneer.com&gt;
/Mtfuji_7/Proposal/Apr09
 DVD-Download.pdf
 Power_management.pdf
 GET_CONFIGURATION.pdf
 GET_EVENT_STATUS_NOTIFICATION.pdf
 commnet_fuji7-9.pdf
 AN_timing_090416.pdf
 AACS Feature.pdf
/Mtfuji_7/Minutes
 DraftMinApr09.pdf
 MinSep08.pdf
Please send any comments by April 24 to discuss in the next MMC at Seattle,
WA
USA.
I asked Bob Griswold about MMC on Wednesday May 6.
MMC may be moved to May 6. Please check T10 website.
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 Gerry.Houlder at seagate.com  Mon Apr 20 15:47:30 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 20 Apr 2009 17:47:30 -0500
Subject: Question on Log Select with PCR=1, SP=1
Message-ID: <mailman.254.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Hi gang,
While looking at SPC-4 rev. 18, clause 6.5.2, table 143, I came across some
unexpected behavior.
The rows for PCR=1, SP=1, and PC= 00b and 01b define the operation as:
1) save the current values;
2) reset values to defaults.
This will (normally) result in the saved and current values being different
at the end of the LOG SELECT command. This is at odds with the defined
behavior for MODE SELECT, where values are updated/ reset first, then
saved.	LOG SELECT with PCR=0 and SP=1 will also update the Log parameters
first, then save them. Why did this get turned around backwards for the
PCR=1 case? Is this really the implementation we want?
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Mon Apr 20 19:12:52 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 20 Apr 2009 19:12:52 -0700
Subject: 08-390r0 [SSC-3: Letter Ballot SYM-019 item a resolution] has been posted
Message-ID: <mailman.255.1441607349.22516.t10@sandbox.t10.org>

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

I have posted a proposal to resolve SSC-3 Letter Ballot comment SYM-019 
part a.
2009/04/20 19:39:14 
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-390r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From kdbutt at us.ibm.com  Tue Apr 21 14:58:13 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Tue, 21 Apr 2009 14:58:13 -0700
Subject: SSC-3: Encryption Attributes (09-089r0)
Message-ID: <mailman.256.1441607349.22516.t10@sandbox.t10.org>

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

I have uploaded a proposal to the T10 website related to encryption 
attributes.  This allows for controlling how encryption keys are used, 
protected, created, modified, etc.  I plan on discussing this in Bellevue. 
 This is not a trivial addition to SSC-3 and it would behoove those 
interested to review it prior to the SSC-3 WG meeting.
Your request to upload a file or files to the T10 site has been accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-089r0.pdf
Normally, the posting/archiving process takes about 30 minutes.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From mikeb at bustrace.com  Tue Apr 21 15:52:13 2009
From: mikeb at bustrace.com (Mike Berhan)
Date: Tue, 21 Apr 2009 15:52:13 -0700
Subject: Request Sense DESC bit, minor conflict between MMC-6 and SPC-4
Message-ID: <mailman.257.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
The MMC specification refers one to SPC-3 for the Request Sense CDB
definition.  It states this regarding the DESC bit in the CDB:
"Since MM Drives support only a 32-bit LBA format, MM Drives ignore the
setting of the Desc bit in the
REQUEST SENSE command CDB and return only fixed format sense data.
SPC-3 does not seem to be specific (unless I've missed it) on what the drive
should do if it doesn't support Descriptor format sense data but receives a
DESC=1 request.  However, SPC-4 is very clear on this in Table 251 (DESC
bit).  It states:
"The device server shall return no parameter data and terminate the REQUEST
SENSE command with CHECK CONDITION status with the sense key set to ILLEGAL
REQUEST and the additional sense code set to INVALID FIELD IN CDB."
A quick test of the optical drives I have attached show that they do ignore
the DESC bit thereby meeting the MMC requirement but contradicting the SPC
requirement.  This is a minor issue as I suspect no optical software (other
than test software) issues a Request Sense with the DESC bit set.  It is a
conflict between MMC-6 and SPC-4 that I don't believe has been mentioned
before.
It seems to me that MMC-6 should adopt what SPC-4 has defined but I'll leave
that to the two committees if they're interested in addressing this.
Regards,
Mike
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Tue Apr 21 16:39:21 2009
From: roweber at IEEE.org (Ralph Weber)
Date: Tue, 21 Apr 2009 18:39:21 -0500
Subject: Request Sense DESC bit, minor conflict between MMC-6 and SPC-4
Message-ID: <mailman.258.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
Mike,
To my mind, the SPC-3 wording represents the typical T10 approach
to handling Reserved bits that are subsequently given a new meaning
(i.e., the sender of the new bit setting must be prepared to
deal with old-device behaviors).
In SPC-4, CAP apparently felt that the normal Reserved bit rules
no longer applied when it approved 06-264r2:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=06-264r2.pdf
SPC-4 REQUEST SENSE parameter data clarifications [Elliott]
Now that you have exposed the question, I guess CAP will have
to reconsider how best to represent backwards compatibility
in this regard (or even whether backwards compatibility matters).
All the best,
.Ralph
Mike Berhan wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mike Berhan" <mikeb at bustrace.com>
> *
> The MMC specification refers one to SPC-3 for the Request Sense CDB
> definition.  It states this regarding the DESC bit in the CDB:
>
> "Since MM Drives support only a 32-bit LBA format, MM Drives ignore the
> setting of the Desc bit in the
> REQUEST SENSE command CDB and return only fixed format sense data.
>
> SPC-3 does not seem to be specific (unless I've missed it) on what the
drive
> should do if it doesn't support Descriptor format sense data but receives a
> DESC=1 request.  However, SPC-4 is very clear on this in Table 251 (DESC
> bit).  It states:
>
> "The device server shall return no parameter data and terminate the REQUEST
> SENSE command with CHECK CONDITION status with the sense key set to ILLEGAL
> REQUEST and the additional sense code set to INVALID FIELD IN CDB."
>
> A quick test of the optical drives I have attached show that they do ignore
> the DESC bit thereby meeting the MMC requirement but contradicting the SPC
> requirement.	This is a minor issue as I suspect no optical software (other
> than test software) issues a Request Sense with the DESC bit set.  It is a
> conflict between MMC-6 and SPC-4 that I don't believe has been mentioned
> before.
>
> It seems to me that MMC-6 should adopt what SPC-4 has defined but I'll
leave
> that to the two committees if they're interested in addressing this.
>
> Regards,
>
> Mike
>
>
> *
> * 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 kenji.akahoshi.hr at hitachi.com  Wed Apr 22 00:17:19 2009
From: kenji.akahoshi.hr at hitachi.com (kenji.akahoshi.hr at hitachi.com)
Date: Wed, 22 Apr 2009 16:17:19 +0900
Subject: [MtFuji][MMC] Next meeting schedule
Message-ID: <mailman.259.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <kenji.akahoshi.hr at hitachi.com>
*
Hello Bill
I am writing to confirm next MMC & Fuji meeting schedule(date & place).
Katata-san made a request to arrange the schedule several weeks ago.
But I have not received your reply yet.
Do you have any information about that?
(T10 Meeting Information doesn't update yet.)
Most of Japanese attendee will take a long vacation from April 29th (or
25th).
Therefore I would appreciate it if you could let us know the schedule as soon
as possible.
Best Regards,
Kenji Akahoshi
Hitachi
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Alvin.Cox at seagate.com  Wed Apr 22 12:59:20 2009
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 22 Apr 2009 14:59:20 -0500
Subject: Reminder: SAS-2.1 PHY WG teleconference, 4/23, 10:00 am CDT
Message-ID: <mailman.260.1441607349.22516.t10@sandbox.t10.org>

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

Agenda:
SAS 2.1 QSFP+ draft spec proposal (09-084) [Palkert]
Changes to incorporate MiniSAS HD into SAS 2.1 [Cox,Neer]
New items
Teleconference April 23, 2009 10:00 am CDT 
USA Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Topic: SAS-2.1 PHY WG 
Date: Every 23rd April, from Thursday, April 23, 2009 to no end date 
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago) 
Meeting Number: 826 515 680 
Meeting Password: newsas 
Please click the link below to see more information, or to join the 
meeting. 
------------------------------------------------------- 
To join the online meeting 
------------------------------------------------------- 
1. Go to 
https://seagate.webex.com/seagate/j.php?ED=90748572&UID=0&PW=0050021613150e14 2. Enter your name and email address. 
3. Enter the meeting password: newsas 
4. Click "Join Now". 
------------------------------------------------------- 
To join the meeting on iPhone 
------------------------------------------------------- 
Go to 
wbx://seagate.webex.com/seagate?MK=826515680&MPW=01ea72c3e60049b833c3331a04fc
06e7ee07244dbd7a11bf36ceb45110fa6ca6 
Don't have the iPhone WebEx application yet? 
Go to 
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=298844386 
------------------------------------------------------- 
For assistance 
------------------------------------------------------- 
1. Go to https://seagate.webex.com/seagate/mc 
2. On the left navigation bar, click "Support". 
To update this meeting to your calendar program (for example Microsoft 
Outlook), click this link: 
https://seagate.webex.com/seagate/j.php?ED=90748572&UID=0&ICS=MRS2&LD=1&RD=2&
ST=1&SHA2=SVyTzTdCGzSIxsgaH07Ohz1skP261RTOA-QjHZRNW6c= 
WebEx will automatically setup Meeting Manager for Windows the first time 
you join a meeting. To save time, you can setup prior to the meeting by 
clicking this link: 
https://seagate.webex.com/seagate/meetingcenter/mcsetup.php 
Alvin Cox
Seagate Technology, LLC
Office 405-392-3738
Cell 405-206-4809


From billmc37 at ctesc.net  Wed Apr 22 16:12:53 2009
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Wed, 22 Apr 2009 18:12:53 -0500
Subject: [MtFuji][MMC] Next meeting schedule
Message-ID: <mailman.261.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Sir:
We have requested that the T10 sponsor provide a room for 20 people on 
Wednesday, 6-May. We received a response that the room will be made 
available.
Kind Regards,
Bill McFerrin
kenji.akahoshi.hr at hitachi.com wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * <kenji.akahoshi.hr at hitachi.com>
> *
> Hello Bill
>
> I am writing to confirm next MMC & Fuji meeting schedule(date & place).
> Katata-san made a request to arrange the schedule several weeks ago.
>
> But I have not received your reply yet.
> Do you have any information about that?
> (T10 Meeting Information doesn't update yet.)
>
> Most of Japanese attendee will take a long vacation from April 29th (or
25th).
> Therefore I would appreciate it if you could let us know the schedule as
soon as possible.
>
>
> Best Regards,
>
> Kenji Akahoshi
> Hitachi
>
> *
> * 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 katharine.schmidtke at finisar.com  Thu Apr 23 11:04:19 2009
From: katharine.schmidtke at finisar.com (Katharine Schmidtke)
Date: Thu, 23 Apr 2009 11:04:19 -0700
Subject: SAS PHY Working Group Conference Call April 23 2009
Message-ID: <mailman.262.1441607349.22516.t10@sandbox.t10.org>

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

Regarding today's discussion of Document 09-098r1 "Proposal for SAS 2.1
Specification for Active Cable Electrical Characteristics" being made by
Gourgen Oganessyan (Quellan). 
During the call Mark Seidel (Intel) raised the question of how optical
cables should be handled in this specification with particular regard to
the jitter specification.
In further discussion between Matt Davis (Zarlink), Tom Palkert
(Luxtera), Gourgen Oganessyan (Quellan), and Katharine Schmidkte
(Finisar) it was agreed that optical cables would meet the same jitter
requirement as active copper cables.  This is defined in Table 89 -
"Active cable output electrical characteristics for trained 6 Gbps" of
document 09-098r1.  Gourgen is finalizing this document based on
feedback from today's call and will post the revisions early next week.
Please respond with comments to the reflector so that the group can
discuss.
Regards
Katharine
Katharine Schmidtke, Ph.D.
Strategic Marketing Manager
katharine.schmidtke at finisar.com 
Cell: 408-368-5437
www.finisar.com <http://www.finisar.com&gt; 


From curtis.stevens at wdc.com  Thu Apr 23 12:54:16 2009
From: curtis.stevens at wdc.com (Curtis Stevens)
Date: Thu, 23 Apr 2009 12:54:16 -0700
Subject: SAT Telecon Notes
Message-ID: <mailman.263.1441607349.22516.t10@sandbox.t10.org>

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

Attached at the meeting notes from the SAT telecom held  23-Apr 10am-12am
PT.
-------------------------------------------------
Curtis E. Stevens
Sr. Staff  Engr - Standards & Features Technology
20511 Lake Forest Drive #A 113-F
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com  


From jgeldman at lexar.com  Sat Apr 25 03:14:06 2009
From: jgeldman at lexar.com (jgeldman at lexar.com)
Date: Sat, 25 Apr 2009 03:14:06 -0700
Subject: Updated proposal to the Trusted Flash SP assignment
Message-ID: <mailman.264.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* <jgeldman at lexar.com>
*
08-289r1 has been posted. This is the proposal to revoke the SPC-4
Trusted Flash SP assignment.
The document clarifies the current status of Trusted Flash as a vendor
licensed protocol, as opposed to the industry group protocol it was
initially proposed as.
2009/04/25 04:02:14 
Your request to upload a file or files to the T10 site has been
accepted.
Your PDF file will be posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-289r1.pdf
Regards,
John Geldman
Director of Industry Standards
Lexar Media
47300 Bayside Parkway
Fremont, CA 94538
P: 510 580-8715
C: 510 449-3597
*
* 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 Apr 25 23:01:01 2009
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 26 Apr 2009 00:01:01 -0600
Subject: Recent T10 documents uploaded since 2009/04/19
Message-ID: <mailman.265.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
ADC-3: Remove Configure Encryption Policy mounted volume restriction
(by: Rod Wideman)
T10/08-247r2   Uploaded: 2009/04/21   16537 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-247r2.pdf
Revoking the provisional TrustedFlash Security Protocol Assignment
(SPC-4)
(by: John Geldman)
T10/08-289r1   Uploaded: 2009/04/25   117621 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-289r1.pdf
SSC-3: Letter Ballot SYM-019 item a resolution
(by: Kevin Butt)
T10/08-390r0   Uploaded: 2009/04/20   90283 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-390r0.pdf
SAS-2.1 / SPL An optical OOB method
(by: Brian Day)
T10/08-439r3   Uploaded: 2009/04/20   194121 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-439r3.pdf
SPC-4: Device constituent VPD page
(by: Kevin Butt)
T10/09-033r3   Uploaded: 2009/04/21   88521 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-033r3.pdf
SPC-4, Rectifying conflicts for DEVOFFL and UNITOFFL
(by: Mark Evans)
T10/09-087r1   Uploaded: 2009/04/22   19811 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-087r1.pdf
SSC-3: Encryption Attributes
(by: Kevin Butt)
T10/09-089r0   Uploaded: 2009/04/21   159061 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-089r0.pdf
SAT-2 Standby translation modifications
(by: William Martin)
T10/09-113r2   Uploaded: 2009/04/23   114038 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-113r2.pdf
Results of Letter Ballot on forwarding UAS to first public review
(by: John Lohmeyer)
T10/09-132r0   Uploaded: 2009/04/24   306669 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-132r0.pdf
Results of Letter Ballot on forwarding UAS to first public review
(by: John Lohmeyer)
T10/09-132r0   Uploaded: 2009/04/24   131250 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-132r0.txt
SSC-3: Tape end-to-end data protection(Presentation)
(by: Kevin Butt)
T10/09-152r0   Uploaded: 2009/04/22   116627 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-152r0.pdf
SSC-3: Tape end-to-end data protection(Presentation)
(by: Kevin Butt)
T10/09-152r0   Uploaded: 2009/04/21   172544 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-152r0.ppt
Working Drafts
--------------
(Report generated on 2009/04/26 at 00:01:01)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From George.Penokie at lsi.com  Mon Apr 27 06:26:22 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Mon, 27 Apr 2009 07:26:22 -0600
Subject: SPL disparity errors counter conflict
Message-ID: <mailman.266.1441607349.22516.t10@sandbox.t10.org>

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

How is it possible for one counter to have two diametrically opposed
characteristics? A single counter cannot be both wrapping and saturating at
the same time.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Tuesday, April 14, 2009 8:32 PM
To: t10 at t10.org
Subject: RE: SPL disparity errors counter conflict
Both.
When reported via the old REPORT PHY ERROR LOG function, they are always
saturating values.  They can be cleared with the PHY CONTROL function CLEAR
ERROR LOG phy operation, but that's not multi-initiator friendly.
When reported via the REPORT PHY EVENT LIST function (if those events have
been selected as sources - there are many other sources also available), they
are wrapping values.  These are multi-initiator friendly.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Tuesday, April 14, 2009 6:45 PM
To: t10 at t10.org
Subject: SPL disparity errors counter conflict
The running disparity errors counter in SPL (and SAS-2) in two places is
called out as a saturating counter and one place as a wrapping counter. (see
below for the wording) Note that WC stands for wrapping counter.
So which is it. It appears that the specification in table 37 (SPL r1) is not
correct, any comments.
4.11 Phy events
Phys shall count the following events using saturating counters and report
them in the Protocol-Specific Port log page (see 9.2.8.1) and/or the SMP
REPORT PHY ERROR LOG function (see 9.4.3.11):
a) invalid dwords received;
b) dwords received with running disparity errors;
c) loss of dword synchronization; and
d) phy reset problems.
Table 37 - PHY EVENT SOURCE field (part 1 of 4)
02h Running disparity error count	     WC        Number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences
9.4.3.11 REPORT PHY ERROR LOG function
The RUNNING DISPARITY ERROR COUNT field indicates the number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences. The count shall stop at the maximum value.
The RUNNING DISPARITY ERROR COUNT field is set to a vendor-specific value
after power on.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com


From Kevin_Marks at Dell.com  Mon Apr 27 08:59:06 2009
From: Kevin_Marks at Dell.com (Kevin_Marks at Dell.com)
Date: Mon, 27 Apr 2009 10:59:06 -0500
Subject: SPL disparity errors counter conflict
Message-ID: <mailman.267.1441607349.22516.t10@sandbox.t10.org>

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

I think of them more as two counters, counting the same thing, one
wrapping, one saturating. This also applies to the other 3 original
counters.
Kevin
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Monday, April 27, 2009 8:26 AM
To: Elliott, Robert (Server Storage); t10 at t10.org
Subject: RE: SPL disparity errors counter conflict
How is it possible for one counter to have two diametrically opposed
characteristics? A single counter cannot be both wrapping and saturating
at the same time. 
Bye for now, 
George Penokie 
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901 
507-328-9017 
george.penokie at lsi.com 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Tuesday, April 14, 2009 8:32 PM
To: t10 at t10.org
Subject: RE: SPL disparity errors counter conflict
Both.  
When reported via the old REPORT PHY ERROR LOG function, they are always
saturating values.  They can be cleared with the PHY CONTROL function
CLEAR ERROR LOG phy operation, but that's not multi-initiator friendly.
When reported via the REPORT PHY EVENT LIST function (if those events
have been selected as sources - there are many other sources also
available), they are wrapping values.  These are multi-initiator
friendly.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Tuesday, April 14, 2009 6:45 PM
To: t10 at t10.org
Subject: SPL disparity errors counter conflict
The running disparity errors counter in SPL (and SAS-2) in two places is
called out as a saturating counter and one place as a wrapping counter.
(see below for the wording) Note that WC stands for wrapping counter.
So which is it. It appears that the specification in table 37 (SPL r1)
is not correct, any comments.
4.11 Phy events
Phys shall count the following events using saturating counters and
report them in the Protocol-Specific Port log page (see 9.2.8.1) and/or
the SMP REPORT PHY ERROR LOG function (see 9.4.3.11):
a) invalid dwords received;
b) dwords received with running disparity errors;
c) loss of dword synchronization; and
d) phy reset problems.
Table 37 - PHY EVENT SOURCE field (part 1 of 4)
02h Running disparity error count	     WC        Number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences
9.4.3.11 REPORT PHY ERROR LOG function
The RUNNING DISPARITY ERROR COUNT field indicates the number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences. The count shall stop at the maximum
value. The RUNNING DISPARITY ERROR COUNT field is set to a
vendor-specific value after power on.
Bye for now, 
George Penokie
LSI Corporation 
3033 41st St. NW 
Suite 100 
Rochester, MN 55901
507-328-9017 
george.penokie at lsi.com


From George.Penokie at lsi.com  Mon Apr 27 13:05:29 2009
From: George.Penokie at lsi.com (Penokie, George)
Date: Mon, 27 Apr 2009 14:05:29 -0600
Subject: SPL disparity errors counter conflict
Message-ID: <mailman.268.1441607349.22516.t10@sandbox.t10.org>

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

Rob,
OK, so everyone tells me there has to be two counters to make this work. But
that's not the issue.
The issue is that in section 4.11 The first paragraph states that the
Protocol-Specific Port log page has the counters as saturating and then a few
paragraphs down there is a statement+table that indicates that the
Protocol-Specific Port log page has the counters as wrapping. If you look in
the Protocol-Specific Port page the fields that hold the counters point to
the SMP REPORT PHY ERROR LOG function that states the counters are
saturating. It appear to me like the entry in the table description that
lists the Protocol-Specific Port log page is wrong and needs to be deleted.
If that is not the case then someone will have to explain to me how anyone
can figure out which if the two counters to place into the Protocol-Specific
Pot log page.
4.11 Phy events
Phys shall count the following events using saturating counters and report
them in the Protocol-Specific Port log page (see 9.2.8.1) and/or the SMP
REPORT PHY ERROR LOG function (see 9.4.3.11):
invalid dwords received;
dwords received with running disparity errors;
loss of dword synchronization; and
phy reset problems.
...
The phy event source field, defined in ?able 1, is used in the
Protocol-Specific Port log page (see 9.2.8.1), the REPORT PHY EVENT function
(see 9.4.3.14), the REPORT PHY EVENT LIST function (see 9.4.3.16), and the
CONFIGURE PHY EVENT function (see 9.4.3.30) and indicates or specifies the
type of phy event in the accompanying phy event field.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Monday, April 27, 2009 8:26 AM
To: Elliott, Robert (Server Storage); t10 at t10.org
Subject: RE: SPL disparity errors counter conflict
How is it possible for one counter to have two diametrically opposed
characteristics? A single counter cannot be both wrapping and saturating at
the same time.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Tuesday, April 14, 2009 8:32 PM
To: t10 at t10.org
Subject: RE: SPL disparity errors counter conflict
Both.
When reported via the old REPORT PHY ERROR LOG function, they are always
saturating values.  They can be cleared with the PHY CONTROL function CLEAR
ERROR LOG phy operation, but that's not multi-initiator friendly.
When reported via the REPORT PHY EVENT LIST function (if those events have
been selected as sources - there are many other sources also available), they
are wrapping values.  These are multi-initiator friendly.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Tuesday, April 14, 2009 6:45 PM
To: t10 at t10.org
Subject: SPL disparity errors counter conflict
The running disparity errors counter in SPL (and SAS-2) in two places is
called out as a saturating counter and one place as a wrapping counter. (see
below for the wording) Note that WC stands for wrapping counter.
So which is it. It appears that the specification in table 37 (SPL r1) is not
correct, any comments.
4.11 Phy events
Phys shall count the following events using saturating counters and report
them in the Protocol-Specific Port log page (see 9.2.8.1) and/or the SMP
REPORT PHY ERROR LOG function (see 9.4.3.11):
a) invalid dwords received;
b) dwords received with running disparity errors;
c) loss of dword synchronization; and
d) phy reset problems.
Table 37 - PHY EVENT SOURCE field (part 1 of 4)
02h Running disparity error count	     WC        Number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences
9.4.3.11 REPORT PHY ERROR LOG function
The RUNNING DISPARITY ERROR COUNT field indicates the number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences. The count shall stop at the maximum value.
The RUNNING DISPARITY ERROR COUNT field is set to a vendor-specific value
after power on.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com


From kdbutt at us.ibm.com  Mon Apr 27 21:18:42 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 27 Apr 2009 21:18:42 -0700
Subject: SPC-4: Team Reservation (08-025r4)
Message-ID: <mailman.269.1441607349.22516.t10@sandbox.t10.org>

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

I have finally updated my Team Reservations proposal.  I noticed there had 
been no work done on this in one year (last work was March 2008 CAP 
meeting) and I got embarrassed.  An update has been posted.
2009/04/27 22:08: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/cgi-bin/ac.pl?t=d&f=08-025r4.pdf
Normally, the posting/archiving process takes about 30 minutes.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


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

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


From Frederick.Knight at netapp.com  Tue Apr 28 07:22:04 2009
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Tue, 28 Apr 2009 10:22:04 -0400
Subject: ACA condition
Message-ID: <mailman.271.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
The discussion on the reflector about ACA and the required response when
an ACA condition does not exist generated some inconsistent
interpretations (SAM vs. FCP).
So I've posted document 09-159 to start discussion on this.  I
appreciate folks taking a look to see what their products do for this
case so we can have a useful discussion next week.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-159r0.pdf
	Fred Knight
*
* 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  Tue Apr 28 12:42:41 2009
From: daviburg at windows.microsoft.com (David Burg)
Date: Tue, 28 Apr 2009 12:42:41 -0700
Subject: MMC/Fuji: Media default rotation control is the rotation control is
 defined by specifications
Message-ID: <mailman.272.1441607349.22516.t10@sandbox.t10.org>

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

Hello,
Our team is currently experiencing some challenging time understanding how to
make use of the write speed descriptors and in particular the write rotation
control field. The specs says:
"Media default rotation control is the rotation control is defined by media
specifications."
Well, that is actually not so helpful as it fails to abstract the protocol
|from the media specifics, i.e. it requires the host to have specific
knowledge of the device / media. Then the MMC specification tries to be
helpful by adding a table of 'typical' default rotation controls.
What does 'typical' mean? Does it mean recommended but not mandatory and
really up to the media specification to say? Or it is a mandatory default
rotation control for the 'typical' media types listed in the table?
Furthermore the table is ambiguous is that it says 'DVD-R/-RW' but only
'DVD+RW'. What about DVD+R then? And do the entry cover only SL or is DL also
mandated by these entries?
The spec then says "If default rotation control is CAV, this field shall be
set to zero." - but there is not a single entry in the table where the
default rotation control is CAV. So this statement is quite weird. What
is/are the media for which the default rotation control is CAV?
Is there any way for the host to query what is the 'media default rotation
control' using MMC or Fuji?
With regards,
David.


From Elliott at hp.com  Tue Apr 28 17:49:45 2009
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 29 Apr 2009 00:49:45 +0000
Subject: SPL disparity errors counter conflict
Message-ID: <mailman.273.1441607349.22516.t10@sandbox.t10.org>

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

The Protocol-Specific Port log page may contain both versions of the
counters:
a) It always contains the saturating versions in bytes 32-47 of the SAS phy
log descriptor;
b) It may also contain the wrapping versions in bytes 52-m of the SAS phy log
descriptor in the phy event descriptor, if the logical unit chooses to
implement those phy event sources (that selection is vendor-specific).
From: Penokie, George [mailto:George.Penokie at lsi.com]
Sent: Monday, April 27, 2009 3:05 PM
To: Penokie, George; Elliott, Robert (Server Storage); t10 at t10.org
Subject: RE: SPL disparity errors counter conflict
Rob,
OK, so everyone tells me there has to be two counters to make this work. But
that's not the issue.
The issue is that in section 4.11 The first paragraph states that the
Protocol-Specific Port log page has the counters as saturating and then a few
paragraphs down there is a statement+table that indicates that the
Protocol-Specific Port log page has the counters as wrapping. If you look in
the Protocol-Specific Port page the fields that hold the counters point to
the SMP REPORT PHY ERROR LOG function that states the counters are
saturating. It appear to me like the entry in the table description that
lists the Protocol-Specific Port log page is wrong and needs to be deleted.
If that is not the case then someone will have to explain to me how anyone
can figure out which if the two counters to place into the Protocol-Specific
Pot log page.
4.11 Phy events
Phys shall count the following events using saturating counters and report
them in the Protocol-Specific Port log page (see 9.2.8.1) and/or the SMP
REPORT PHY ERROR LOG function (see 9.4.3.11):
invalid dwords received;
dwords received with running disparity errors;
loss of dword synchronization; and
phy reset problems.
...
The phy event source field, defined in ?able 1, is used in the
Protocol-Specific Port log page (see 9.2.8.1), the REPORT PHY EVENT function
(see 9.4.3.14), the REPORT PHY EVENT LIST function (see 9.4.3.16), and the
CONFIGURE PHY EVENT function (see 9.4.3.30) and indicates or specifies the
type of phy event in the accompanying phy event field.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Monday, April 27, 2009 8:26 AM
To: Elliott, Robert (Server Storage); t10 at t10.org
Subject: RE: SPL disparity errors counter conflict
How is it possible for one counter to have two diametrically opposed
characteristics? A single counter cannot be both wrapping and saturating at
the same time.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott,
Robert (Server Storage)
Sent: Tuesday, April 14, 2009 8:32 PM
To: t10 at t10.org
Subject: RE: SPL disparity errors counter conflict
Both.
When reported via the old REPORT PHY ERROR LOG function, they are always
saturating values.  They can be cleared with the PHY CONTROL function CLEAR
ERROR LOG phy operation, but that's not multi-initiator friendly.
When reported via the REPORT PHY EVENT LIST function (if those events have
been selected as sources - there are many other sources also available), they
are wrapping values.  These are multi-initiator friendly.
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie,
George
Sent: Tuesday, April 14, 2009 6:45 PM
To: t10 at t10.org
Subject: SPL disparity errors counter conflict
The running disparity errors counter in SPL (and SAS-2) in two places is
called out as a saturating counter and one place as a wrapping counter. (see
below for the wording) Note that WC stands for wrapping counter.
So which is it. It appears that the specification in table 37 (SPL r1) is not
correct, any comments.
4.11 Phy events
Phys shall count the following events using saturating counters and report
them in the Protocol-Specific Port log page (see 9.2.8.1) and/or the SMP
REPORT PHY ERROR LOG function (see 9.4.3.11):
a) invalid dwords received;
b) dwords received with running disparity errors;
c) loss of dword synchronization; and
d) phy reset problems.
Table 37 - PHY EVENT SOURCE field (part 1 of 4)
02h Running disparity error count	     WC        Number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences
9.4.3.11 REPORT PHY ERROR LOG function
The RUNNING DISPARITY ERROR COUNT field indicates the number of dwords
containing running disparity errors (see 5.3.5) that have been received
outside of phy reset sequences. The count shall stop at the maximum value.
The RUNNING DISPARITY ERROR COUNT field is set to a vendor-specific value
after power on.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com


From Paul.Suhler at Quantum.Com  Wed Apr 29 10:55:06 2009
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Wed, 29 Apr 2009 11:55:06 -0600
Subject: T10 Agenda
Message-ID: <mailman.274.1441607349.22516.t10@sandbox.t10.org>

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

 <<adi-agnd.txt>> 


From Paul.Suhler at Quantum.Com  Wed Apr 29 10:54:05 2009
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Wed, 29 Apr 2009 11:54:05 -0600
Subject: T10 Agenda
Message-ID: <mailman.275.1441607349.22516.t10@sandbox.t10.org>

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

 <<adi-agnd.txt>> 


From Paul.Suhler at Quantum.Com  Wed Apr 29 11:35:34 2009
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Wed, 29 Apr 2009 12:35:34 -0600
Subject: Gratuitous Agenda
Message-ID: <mailman.276.1441607349.22516.t10@sandbox.t10.org>

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

Apologies for sending the ADI agenda to the wrong address.
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com 


From kdbutt at us.ibm.com  Wed Apr 29 16:22:52 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 29 Apr 2009 16:22:52 -0700
Subject: 09-085r1 Power Condition Transition modifications
Message-ID: <mailman.277.1441607349.22516.t10@sandbox.t10.org>

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

I have an issue with 09-085r1.	The suggested changes to SPC-4 assume that 
every device that uses power conditions and the power condition mode page 
support the START/STOP UNIT command and its controlling of power 
conditions.  Since this is in SPC-4 this applies to all devices including 
SSC (i.e., Tape) and SMC (i.e., library) devices and neither of these 
devices support START/STOP UNIT - nor can they because the opcode is 
LOAD/UNLOAD - whatever is proposed needs to make the distinction between 
those devices.	I don't know if the solution is to exclude SSC and SMC 
devices or to explicitly state that the statements only apply to SBC 
devices or to have a list of behaviors depending on device type.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From Paul.Suhler at Quantum.Com  Wed Apr 29 17:20:31 2009
From: Paul.Suhler at Quantum.Com (Paul Suhler)
Date: Wed, 29 Apr 2009 18:20:31 -0600
Subject: Revised:  ADC-3:  I_T Nexus Loss Effect on Bridged Commands (T10/08-301r2)
Message-ID: <mailman.278.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Paul Suhler" <Paul.Suhler at Quantum.Com>
*
In response to a suggestion from Kevin Butt, I have revised 08-301r1.
The new proposal is:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-301r2.pdf
thanks very much,
Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suhler at quantum.com 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Black_David at emc.com  Wed Apr 29 17:25:44 2009
From: Black_David at emc.com (Black_David at emc.com)
Date: Wed, 29 Apr 2009 20:25:44 -0400
Subject: New Thin Provisioning Document: 08-341r1 GET LBA STATUS
Message-ID: <mailman.279.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Black_David at emc.com
*
I just uploaded 08-341r1, SBC-3: GET LBA STATUS command:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-341r1.pdf
Despite the innocuous-sounding name, this is the proposal
(mentioned on the most recent thin provisioning call) 
for a new command to report whether blocks on an thinly
provisioned logical unit are mapped or not.
The proposal is for discussion-only next week - I do not
intend to move for its incorporation.
Enjoy,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953	      FAX: +1 (508) 293-7786
black_david at emc.com	   Mobile: +1 (978) 394-7754
----------------------------------------------------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Kevin_Marks at Dell.com  Wed Apr 29 18:50:57 2009
From: Kevin_Marks at Dell.com (Kevin_Marks at Dell.com)
Date: Wed, 29 Apr 2009 20:50:57 -0500
Subject: 09-085r1 Power Condition Transition modifications
Message-ID: <mailman.280.1441607349.22516.t10@sandbox.t10.org>

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

Kevin,
I will take a look at it, and see where in the proposal and SPC4 you
think it assumes a block device and START STOP UNIT. Are you talking
about LU Control? I looked thru rev 2 that I am working on, and did not
see the issue. Almost all the SSU command changes are in SBC3.
Kevin
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Wednesday, April 29, 2009 6:23 PM
To: t10 at t10.org
Subject: 09-085r1 Power Condition Transition modifications
I have an issue with 09-085r1.	The suggested changes to SPC-4 assume
that every device that uses power conditions and the power condition
mode page support the START/STOP UNIT command and its controlling of
power conditions.  Since this is in SPC-4 this applies to all devices
including SSC (i.e., Tape) and SMC (i.e., library) devices and neither
of these devices support START/STOP UNIT - nor can they because the
opcode is LOAD/UNLOAD - whatever is proposed needs to make the
distinction between those devices.  I don't know if the solution is to
exclude SSC and SMC devices or to explicitly state that the statements
only apply to SBC devices or to have a list of behaviors depending on
device type. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/
<http://www-03.ibm.com/servers/storage/&gt;  


From jl01881 at jcom.home.ne.jp  Wed Apr 29 21:36:16 2009
From: jl01881 at jcom.home.ne.jp (Y.Horiuchi)
Date: Thu, 30 Apr 2009 13:36:16 +0900
Subject: [MtFuji] Proposal for Mt Fuji / T10 MMC meeting May 6th.
Message-ID: <mailman.281.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Y.Horiuchi" <jl01881 at jcom.home.ne.jp>
*
Leete-san,
Here is my comments on this.
This is very interesting and I would like to work together.  
There are two choice to add in ODD Button SW into PIN assign. Drive presence
or M-Diag.
Then considering side effect of implementation, M-Diag is good for Button SW. Drive presence has used by many PC in the field.
On the other hand, There are
already many drive has customize model for like this circuit in M-Diag. If
M-Diag use as Button SW, the proposal
will be accepted with no big concern.
Regards
---- "Leete $B$5$s$O=q$-$^$7$?(B: 
> Team,
> 
> Here is a proposal for reducing power in the ODD I'd like to discuss in the
T10 MMC meeting May 6th.
> 
> The MtFujiOverview.pdf file contains an overview of the proposal. The
MtFujiProposal_04_24_09.pdf file contains more detail, including some
suggested ways the changes could be introducted into the existing Mt Fuji
spec as it is currently written.
> 
> I look forward to seeing you in the meeting and getting your feedback.
> 
> Brian Leete
> CO5-166
> Intel Corporation
> 1365 NW Amberglen Parkway
> Beaverton, Oregon, 97006
> 503-456-0484
> 
> 
--
Y.Horiuchi ($BKYFb!!9/90!K(B
Lenovo-J
jl01881 at jcom.home.ne.jp
(horiucy at lenovo.com)
*
* 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  Thu Apr 30 10:48:42 2009
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Thu, 30 Apr 2009 10:48:42 -0700
Subject: 09-085r1 Power Condition Transition modifications
Message-ID: <mailman.282.1441607349.22516.t10@sandbox.t10.org>

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

Kevin,
In 5.10.5.4.2 there is a new paragraph about ITC.  BTW, there is an 
unordered list with only one item - oops.
Also 5.10.5.5.2 and 5.10.5.5.3	BTW, there is an unordered list with only 
one item - oops.
You might make the argument that the START STOP UNIT command is not 
required and therefore that it is not necessary to spell out the 
difference, but it does levy a requirement on all devices and I think it 
should be clear.
In 7.4.2 the two new bits are added ITC and STC.  Looking a little closer, 
this is the crux of the issue.	It may be a nit, but tape and library 
devices (and any other) that do not support the START STOP UNIT command 
have a curious choice here.  Either support the bit - and imply the START 
STOP UNIT command which cannot be supported - or not allow the bit to be 
supported - in which case they can't get the in process of becoming ready 
response.  Does there need to be an explicit statement or what?
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:
<Kevin_Marks at Dell.com>
To:
Kevin D Butt/Tucson/IBM at IBMUS, <t10 at t10.org>
Date:
04/29/2009 07:43 PM
Subject:
RE: 09-085r1 Power Condition Transition modifications
Kevin,
I will take a look at it, and see where in the proposal and SPC4 you think 
it assumes a block device and START STOP UNIT. Are you talking about LU 
Control? I looked thru rev 2 that I am working on, and did not see the 
issue. Almost all the SSU command changes are in SBC3.
Kevin
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D 
Butt
Sent: Wednesday, April 29, 2009 6:23 PM
To: t10 at t10.org
Subject: 09-085r1 Power Condition Transition modifications
I have an issue with 09-085r1.	The suggested changes to SPC-4 assume that 
every device that uses power conditions and the power condition mode page 
support the START/STOP UNIT command and its controlling of power 
conditions.  Since this is in SPC-4 this applies to all devices including 
SSC (i.e., Tape) and SMC (i.e., library) devices and neither of these 
devices support START/STOP UNIT - nor can they because the opcode is 
LOAD/UNLOAD - whatever is proposed needs to make the distinction between 
those devices.	I don't know if the solution is to exclude SSC and SMC 
devices or to explicitly state that the statements only apply to SBC 
devices or to have a list of behaviors depending on device type. 
Thanks, 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 


From Gerry.Houlder at seagate.com  Thu Apr 30 11:49:52 2009
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Thu, 30 Apr 2009 13:49:52 -0500
Subject: 09-085r1 Power Condition Transition modifications
Message-ID: <mailman.283.1441607349.22516.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I believe that the SPC-4 text added by Kevin Marks that mentions START STOP
UNIT is of the form "..all commands, except START STOP UNIT, shall do this
..". If you are a device that doesn't support this command, then excepting
this command from the behavior should not be any consequence to you.
There are plenty of other reasons to disagree with this proposal, this
reason is minor compared to those. See you next week.
	     Kevin D Butt						   
	     <kdbutt at us.ibm.co						   
	     m> 							To 
	     Sent by:		       <Kevin_Marks at Dell.com>		   
	     owner-t10 at t10.org						cc 
	     No Phone Info	       t10 at t10.org			   
	     Available						   Subject 
				       RE: 09-085r1 Power Condition	   
				       Transition modifications 	   
	     04/30/2009 12:48						   
	     PM 							   
Kevin,
In 5.10.5.4.2 there is a new paragraph about ITC.  BTW, there is an
unordered list with only one item - oops.
Also 5.10.5.5.2 and 5.10.5.5.3	BTW, there is an unordered list with only
one item - oops.
You might make the argument that the START STOP UNIT command is not
required and therefore that it is not necessary to spell out the
difference, but it does levy a requirement on all devices and I think it
should be clear.
In 7.4.2 the two new bits are added ITC and STC.  Looking a little closer,
this is the crux of the issue.	It may be a nit, but tape and library
devices (and any other) that do not support the START STOP UNIT command
have a curious choice here.  Either support the bit - and imply the START
STOP UNIT command which cannot be supported - or not allow the bit to be
supported - in which case they can't get the in process of becoming ready
response.  Does there need to be an explicit statement or what?
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/
 From:	    <Kevin_Marks at Dell.com>					   
 To:	    Kevin D Butt/Tucson/IBM at IBMUS, <t10 at t10.org>		   
 Date:	    04/29/2009 07:43 PM 					   
 Subject:   RE: 09-085r1 Power Condition Transition modifications	   
Kevin,
I will take a look at it, and see where in the proposal and SPC4 you think
it assumes a block device and START STOP UNIT. Are you talking about LU
Control? I looked thru rev 2 that I am working on, and did not see the
issue. Almost all the SSU command changes are in SBC3.
Kevin
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D
Butt
Sent: Wednesday, April 29, 2009 6:23 PM
To: t10 at t10.org
Subject: 09-085r1 Power Condition Transition modifications
I have an issue with 09-085r1.	The suggested changes to SPC-4 assume that
every device that uses power conditions and the power condition mode page
support the START/STOP UNIT command and its controlling of power
conditions.  Since this is in SPC-4 this applies to all devices including
SSC (i.e., Tape) and SMC (i.e., library) devices and neither of these
devices support START/STOP UNIT - nor can they because the opcode is
LOAD/UNLOAD - whatever is proposed needs to make the distinction between
those devices.	I don't know if the solution is to exclude SSC and SMC
devices or to explicitly state that the statements only apply to SBC
devices or to have a list of behaviors depending on device type.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org