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