SAT Question/Comment

Sheffield, Robert L robert.l.sheffield at intel.com
Thu Aug 11 08:24:56 PDT 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Robert L" <robert.l.sheffield at intel.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C59E88.D4CB29D2
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Kevin,
=20
I agree - the intent is that SAT provide no guidance whatsoever for the
use of fields marked with a SATType of 'U'. We took a straw-poll among
those present at the July meeting and voted 11 to 1 to leave the
description for any fields marked SATType 'U' blank (as opposed to
referencing SBC-2 and/or SPC-3). For any field definitions marked 'U'
that have any "shall", "should", or "may" information in the
description, either that description should be removed, or the SATType
should be changed to an "E" or "I". We need to be diligent about =
finding
and fixing these during review of the working draft and review of
working proposals.
=20
SAT-r05 (posted last Friday) defines the 'U' value of the SATType as
follows:

3.4.3 unspecified: A term indicating that this version of this standard
does not specify a translation for a SCSI protocol element, but does =
not
preclude a future version of this standard defining a translation.
Implementations for fields marked unspecified shall not conflict with
SPC-3 or SBC-2.

While it's tempting (and perhaps necessary in some cases) to interpret
this as guidance to implement vendor-specific behavior, developers of
SAT products should do so with great hesitation. The intent is more =
like
"reserved", because SAT reserves the option to define behavior for =
these
fields in future versions of the standard. In any case, implementations
must still conform to SBC-2 and SPC-3. If vendors identify the need to
pin-down the behavior of a field marked with a SATType of 'U', I
strongly urge them to bring in a proposal specifying the desired
behavior and changing the SATType to 'E' or 'I'.
=20
Regards,
Bob Sheffield
SAT Editor

  _____ =20

From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin_Marks at Dell.com
Sent: Wednesday, August 10, 2005 9:13 PM
To: t10 at t10.org
Subject: SAT Question/Comment



All,

I have question/comment on SAT and the meaning of the E/U SATTypes,
especially the U type.  My interpretation of the U SATtype, is that the
standard does not specify the translation/behavior of this field, which
to me means that I can implement a vendor specific behavior within the
bound of SPC-3, SBC-2, etc.

I have noticed that in many of the current proposals and in SATr05 that
many of the U fields have shall/should and behaviors of reporting CHECK
CONDITIONS or statements of ignoring the field in the Description or
reference column. Shouldn't these be E, and not U.?=20

Not to pick on Steve, but his was the last proposal I looked at. In
05-108r2 SAT-Task Management for example, in Table 1 - Control byte
fields of clause 1.4.1 CONTROL byte overview, the LINK and NACA fields
are both specified as U, and both have behaviors that say if set to one
shall return a CHECK CONDITION, etc. Should these not be E, so that if
for some strange reason I want implement link commands or NACA in the
SATL, I can?

Comments

Thanks

Kevin


Kevin Marks
Dell, Inc.



------_=_NextPart_001_01C59E88.D4CB29D2
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

SAT Question/Comment Kevin,
  
 I agree - the intent is that SAT provide no = guidance=20 whatsoever for the use of fields marked with a SATType of 'U'. We took = a=20 straw-poll among those present at the July meeting and voted 11 to 1 to = leave=20 the description for any fields marked SATType 'U' blank (as opposed to=20 referencing SBC-2 and/or SPC-3). For any field definitions marked 'U' = that have=20 any "shall", "should", or "may" information in the description, either = that=20 description should be removed, or the SATType should be changed to an = "E" or=20 "I". We need to be diligent about finding and fixing these during = review of the=20 working draft and review of working proposals.
  
 SAT-r05 (posted last Friday) defines the 'U' = value of the=20 SATType as follows:
 3.4.3 = unspecified:=20 A term = indicating that=20 this version of this standard does not specify a translation for = a SCSI protocol element, but does = not preclude=20 a future version of this standard defining a translation. Implementations for fields marked = unspecified=20 shall not conflict with SPC-3 or=20 SBC-2.
 While it's tempting (and perhaps necessary in = some cases)=20 to interpret this as guidance to implement vendor-specific behavior, = developers=20 of SAT products should do so with great hesitation. The intent is more = like=20 "reserved", because SAT reserves the option to define behavior for = these fields=20 in future versions of the standard. In any case, implementations must = still=20 conform to SBC-2 and SPC-3. If vendors identify the need to pin-down = the=20 behavior of a field marked with a SATType of 'U', I strongly urge them = to bring=20 in a proposal specifying the desired behavior and changing the SATType = to 'E' or=20 'I'.
  
 Regards,
 Bob Sheffield
 SAT Editor

 From: owner-t10 at t10.org=20 [mailto:owner-t10 at t10.org] On Behalf Of=20 Kevin_Marks at Dell.com
Sent: Wednesday, August 10, 2005 = 9:13=20 PM
To: t10 at t10.org
Subject: SAT=20 Question/Comment


 
All, I have = question/comment=20 on SAT and the meaning of the E/U SATTypes, especially the U=20 type.  My interpretation of the U SATtype, is that the = standard does not specify the translation/behavior of=20 this field, which to me means that I can implement a vendor = specific=20 behavior within the bound of SPC-3, SBC-2, etc. I have = noticed that in=20 many of the current proposals and in SATr05 that many of = the=20 U fields have=20 shall/should and behaviors of reporting = CHECK=20 CONDITIONS = or statements of ignoring the = field in=20 the Description or reference column.=20 Shouldn;t these be E, and not U.? = Not to = pick on Steve, but=20 his was the last proposal I looked at. In 05-108r2 SAT-Task Management for = example,=20 in Table 1 ; Control byte fields of clause 1.4.1 CONTROL byte=20 overview, the LINK and NACA fields are both specified as U, and = both have=20 behaviors that say if set to one shall return a CHECK=20 CONDITION, etc. Should these not be E, so that if for some = strange reason I=20 want implement link commands or NACA in the SATL, I=20 can? Comments Thanks Kevin
 Kevin Marks
Dell, Inc.
 

------_=_NextPart_001_01C59E88.D4CB29D2--





More information about the T10 mailing list