Possible mistake in Access Controls Out command

Banther, Michael michael.banther at hp.com
Thu Sep 2 05:57:34 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Banther, Michael" <michael.banther at hp.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C490EC.6A5203DA
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C490EC.6A5203DA"


------_=_NextPart_002_01C490EC.6A5203DA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ralph,
=20
While reading through the Access Controls portion of SPC-3 (r20a), I
came across a sentence that I suspect says something insensible:

If the error is an unsupported value in the LUN VALUE field, the access
controls coordinator should determine a suggested LUN value that is
unlikely to produce an error while also minimizing the absolute value =
of
the difference of the erroneous default LUN value and the suggested LUN
value.

The sentence occurs in 8.3.3.2.2 The Grant/revoke ACE page four
paragraphs below table 361.
=20
The problem lies in the phrase 'default LUN value'.  The Grant/Revoke
ACE page contains a LUN VALUE field and a DEFAULT LUN field.  It's not
clear from the text to which field 'default LUN value' refers.
=20
To my mind minimizing the absolute difference between the default LUN
and a suggested LUN doesn't make as much sense as minimizing the
absolute difference between the unsupported LUN value and a suggested
LUN.  Presumably the reason the device server uses a minimum distance
metric at all to suggest a value is to give the application client a
value close to what it wants.
=20
Do you agree that a problem exists here, and do you consider a change
|from 'default LUN value' to 'unsupported LUN value' (or something
similar) an editorial or technical change?
=20
Regards,
Michael Banther
Hewlett-Packard Ltd.
Telephone +44 (117) 312-9503
=20

------_=_NextPart_002_01C490EC.6A5203DA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

Message Hi=20 Ralph,
  
 While = reading=20 through the Access Controls portion of SPC-3 (r20a), I came across a = sentence=20 that I suspect says something insensible:
 If the error is an unsupported = value in the=20 LUN VALUE = field, the=20 access controls coordinator = should=20 determine a suggested LUN value that is unlikely to produce an error = while=20 also minimizing the absolute = value of=20 the difference of the erroneous default LUN value and the suggested = LUN=20 value.
 The = sentence occurs=20 in 8.3.3.2.2 The Grant/revoke ACE page four paragraphs below table=20 361.
  
 The = problem lies in=20 the phrase 'default LUN value'.  The Grant/Revoke ACE page = contains a LUN VALUE field = and a DEFAULT LUN = field.  It's not=20 clear from the text to which field 'default LUN value'=20 refers.
  
 To my mind minimizing the absolute difference between the = default LUN and=20 a suggested LUN doesn't make as much sense as minimizing the absolute = difference=20 between the unsupported LUN value and a suggested LUN.  Presumably = the=20 reason the device server uses a minimum distance metric at all to = suggest a=20 value is to give the application client a value close to what it=20 wants.
  
 Do = you agree that a=20 problem exists here, and do you consider a change from 'default LUN = value' to=20 'unsupported LUN value' (or something similar) an editorial or = technical=20 change?
  
 Regards,
 Michael = Banther
 Hewlett-Packard = Ltd.
 Telephone +44 (117)=20 312-9503
  


------_=_NextPart_002_01C490EC.6A5203DA--

------_=_NextPart_001_01C490EC.6A5203DA
Content-Type: text/x-vcard;
	name="BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf"
Content-Transfer-Encoding: base64
Content-Description: BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf
Content-Disposition: attachment;
	filename="BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkJBTlRIRVI7TUlDSEFFTA0KRk46QkFOVEhFUixN
SUNIQUVMIChIUC1Vbml0ZWRLaW5nZG9tLGV4MikNCk9SRzpIUC1Vbml0ZWRLaW5nZG9tLGV4MjtD
NjAwLTUzMDINClRFTDtXT1JLO1ZPSUNFOjMxMi05NTAzDQpURUw7V09SSztWT0lDRTorNDQgMTE3
IDMxMiA5NTAzDQpBRFI7V09SSzo7TVMgMkIyMjs7QlJJU1RPTCwgR0INCkxBQkVMO1dPUks7RU5D
T0RJTkc9UVVPVEVELVBSSU5UQUJMRTpNUyAyQjIyPTBEPTBBQlJJU1RPTCwgR0INCkVNQUlMO1BS
RUY7SU5URVJORVQ6bWljaGFlbF9iYW50aGVyQGhwLmNvbQ0KUkVWOjIwMDMwNzE3VDA4Mjk0OFoN
CkVORDpWQ0FSRA0K

------_=_NextPart_001_01C490EC.6A5203DA--




More information about the T10 mailing list