Comments on T10 proposal 05-101r1

George Penokie gop at us.ibm.com
Tue May 17 14:23:23 PDT 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <gop at us.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 00756A7386257004_=
Content-Type: text/plain; charset="US-ASCII"


Gerry, 

The problem is that the target does not "own" the application tag (i.e.,
ATO bit set to 1) (see below) in the normal case and as a result it
cannot know if the FFFFh is valid or not. 

Without the wording change there is a conflict in that the definition of
the ATO bit when set to zero the application tag is ignored based on the
checking rules (note c of WRPROTECT field)(see below). If the ATO bit is
set to one then the only way the target can use the value is if it has
knowledge of the application clients use of the Application Tag. 

So, just putting the text back to the way it was is not a solution.
There would have to wording placed in several places throughout the two
standards to explain how the FFFFh value in the application tag
overrides all the current rules on associated with ATO and writes. 

If you want to do that then I suggest you submit a proposal with all the
required changes. 

An application tag owner (ATO) bit set to one specifies that the
contents of the LOGICAL BLOCK APPLICATION TAG field in the protection
information (see SBC-2), if any, shall not be modified by the device
server. An ATO bit set to zero specifies that the contents of the
LOGICAL BLOCK APPLICATION TAG field in the protection information, if
any, may be modified by the device server. If the ATO bit is set to
zero, the device server shall ignore the contents of the LOGICAL 
BLOCK APPLICATION TAG field in the protection information when received
|from the application client.

Note c in WRPROTECT table: The device server may check the logical block
application tag if the ATO bit is set to one in the Control mode page
(see SPC-3) and if it has knowledge of the contents of the LOGICAL BLOCK
APPLICATION TAG field. If the WRITE (32) command (see 5.28) is used,
this knowledge is obtained from the EXPECTED LOGICAL BLOCK APPLICATION
TAG field and the LOGICAL BLOCK APPLICATION TAG MASK field in the CDB. 

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880





Gerry.Houlder at seagate.com 
Sent by: owner-t10 at t10.org 


05/17/2005 03:19 PM 

To
t10 at t10.org 

cc

Subject
Comments on T10 proposal 05-101r1

	





* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
This proposal adds wording that states "A LOGICAL BLOCK APPLICATION TAG
field set to FFFFh disables checking of all protection information for
the
logical block when reading from the medium."

I don't believe this restriction is a good idea. This disabling of all
checking should also occur for writes as well.

Consider design of target hardware to implement this function. The
hardware
needs to be designed so that an Application Tag value of FFFFh overrides
any checking that would otherwise be permitted by the RDPROTECT field in
the CDB. Now imagine that the same hardware will be used for checking
data
|from a WRITE command. Is it reasonable that the target should redesign
the
same hardware so that  the WRPROTECT field overrides the Application Tag
value of FFFFh? We don't think so.

If there is another reason (other than just making the wording more
specific) I'd like to hear it. Otherwise I would like to see this change
withdrawn or I make a new proposal that changes the wording to "either
writing or reading".

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



--=_alternative 00756A7386257004_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Gerry,</font>
<br>
<br><font size=2 face="sans-serif">The problem is that the target does
not "own" the application tag (i.e., ATO bit set to 1) (see below)
in the normal case and as a result it cannot know if the FFFFh is valid
or not. </font>
<br>
<br><font size=2 face="sans-serif">Without the wording change there is
a conflict in that the definition of the ATO bit when set to zero the application
tag is ignored based on the checking rules (note c of WRPROTECT field)(see
below). If the ATO bit is set to one then the only way the target can use
the value is if it has knowledge of the application clients use of the
Application Tag. </font>
<br>
<br><font size=2 face="sans-serif">So, just putting the text back to the
way it was is not a solution. There would have to wording placed in several
places throughout the two standards to explain how the FFFFh value in the
application tag overrides all the current rules on associated with ATO
and writes.</font>
<br>
<br><font size=2 face="sans-serif">If you want to do that then I suggest
you submit a proposal with all the required changes.</font>
<br>
<br><font size=2 face="sans-serif">An application tag owner (ATO) bit set
to one specifies that the contents of the LOGICAL BLOCK APPLICATION TAG
field in the protection information (see SBC-2), if any, shall not be modified
by the device server. An ATO bit set to zero specifies that the contents
of the LOGICAL BLOCK APPLICATION TAG field in the protection information,
if any, may be modified by the device server. If the ATO bit is set to
zero, the device server shall ignore the contents of the LOGICAL</font>
<br><font size=2 face="sans-serif">BLOCK APPLICATION TAG field in the protection
information when received from the application client.<br>
</font>
<br><font size=2 face="sans-serif">Note c in WRPROTECT table: The device
server may check the logical block application tag if the ATO bit is set
to one in the Control mode page (see SPC-3) and if it has knowledge of
the contents of the LOGICAL BLOCK APPLICATION TAG field. If the WRITE (32)
command (see 5.28) is used, this knowledge is obtained from the EXPECTED
LOGICAL BLOCK APPLICATION TAG field and the LOGICAL BLOCK APPLICATION TAG
MASK field in the CDB.</font>
<br>
<br><font size=2 face="sans-serif">Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208<br>
External: 507-253-5208 &nbsp; FAX: 507-253-2880<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Gerry.Houlder at seagate.com</b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-t10 at t10.org</font>
<p><font size=1 face="sans-serif">05/17/2005 03:19 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">t10 at t10.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Comments on T10 proposal
05-101r1</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>* From the T10 Reflector (t10 at t10.org), posted by:<br>
* Gerry.Houlder at seagate.com<br>
*<br>
This proposal adds wording that states "A LOGICAL BLOCK APPLICATION
TAG<br>
field set to FFFFh disables checking of all protection information for
the<br>
logical block when reading from the medium."<br>
<br>
I don't believe this restriction is a good idea. This disabling of all<br>
checking should also occur for writes as well.<br>
<br>
Consider design of target hardware to implement this function. The hardware<br>
needs to be designed so that an Application Tag value of FFFFh overrides<br>
any checking that would otherwise be permitted by the RDPROTECT field in<br>
the CDB. Now imagine that the same hardware will be used for checking data<br>
|from a WRITE command. Is it reasonable that the target should redesign
the<br>
same hardware so that &nbsp;the WRPROTECT field overrides the Application
Tag<br>
value of FFFFh? We don't think so.<br>
<br>
If there is another reason (other than just making the wording more<br>
specific) I'd like to hear it. Otherwise I would like to see this change<br>
withdrawn or I make a new proposal that changes the wording to "either<br>
writing or reading".<br>
<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
</tt></font>
<br>
--=_alternative 00756A7386257004_=--





More information about the T10 mailing list