Subject: [Ips] iSCSI: clarification? data-in PDU->command status bit

From: David Weibel <[email-masked]>
Date: Mon, 29 Mar 2004 12:51:30 -0700

[This topic appeared about 6 months ago in email archive without a
clear resolution]

   Based on the iSCSI draft 20 is seems that it is legal for an iSCSI 
target
to set the command status bit in a data-in PDU and either return a SCSI
response PDU or drop the response PDU on a successful CMD completion.

	10.7.3  Flags (byte 1) The last SCSI Data packet sent from a target
	to an initiator for a  SCSI command that completed successfully
	(with a status of GOOD,  CONDITION MET, INTERMEDIATE or INTERMEDIATE
	CONDITION MET) may also  optionally contain the Status for the data
	transfer.  In this case,  Sense Data cannot be sent together with
	the Command Status.  If the  command is completed with an error,
	then the response and sense data  MUST be sent in a SCSI Response
	PDU (i.e., MUST NOT be sent in a  SCSI Data packet). For Bidirectional
	commands, the status MUST be  sent in a SCSI Response PDU.

   I would like to purpose two possible clarifications to close the
interpretation of this bit.

1) Update section 10.7.3 to add a statement similar to the below.

	... If the command status bit is set the target MUST not send a SCSI
	response PDU.

(or) 2) Add a new login parameter that allows the target device to 
notify the
initiator of it's planned implementation of the bit.

	12.XX  CommandStatusResponse
	Use: LO
	Senders: Target
	Scope: SW

	CommandStatusResponse=<boolean-value>

	Examples:

		CommandStatusResponse=No
		CommandStatusResponse=Yes

	Default is Yes

	The CommandStatusResonse is used to define the target implementation
	of the data-in PDU's command status bit.  If CommandStatusResponse is
	Yes then the target MUST followup a data-in PDU containing the command
	status bit set with a scsi reponse PDU.  If CommandStatusResponse is
	No then that target device MUST not send the scsi response PDU.

---

[past email archive postings]
suggestion to drop the S bit -
   http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05757.html
requested clarification on the S bit -
   http://www.pdl.cmu.edu/mailinglists/ips/mail/msg12341.html

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Luben Tuikov <[email-masked]>
Date: Mon, 29 Mar 2004 12:10:46 -0800 (PST)

I don't see the problem.

Task SUCESS:
     If the task successfully completed, then the target MAY set the S bit and
return the sucessful status along with the last Data-In PDU.  This of course
precludes sending SENSE DATA.  No need for separate Response PDU as the task's
lifetime has ended with sending response in the last Data-In PDU with S set.

Or the target may choose to send status in a separate PDU (SCSI Response), thus
S is not set for any Data-In PDU, and SCSI Response PDU follows.

Task FAILURE:
     Response PDU. Sense data if available.

Both cases send a response.

-- 
Luben

---

From: Julian Satran <[email-masked]>
Date: Tue, 30 Mar 2004 16:52:04 +0200

Sorry David. iSCSI operates as SCSI transport. SCSI mandates that the 
status is sent once (SAM2) only.
As for your login parameter besides being far too late for such a change I 
do not see why we should mandate this regularity when the code has to be 
there to handle both anyhow.
What you suggest will only change the location of the bit tested.

Julo

David Weibel <[email-masked]> 
Sent by: [email-masked]
29/03/04 21:51

To
[email-masked]
cc

Subject
[Ips] iSCSI: clarification? data-in PDU->command status bit

                 10.7.3  Flags (byte 1) The last SCSI Data packet sent 
from a target
                 to an initiator for a  SCSI command that completed 
successfully
                 (with a status of GOOD,  CONDITION MET, INTERMEDIATE or 
INTERMEDIATE
                 CONDITION MET) may also  optionally contain the Status 
for the data
                 transfer.  In this case,  Sense Data cannot be sent 
together with
                 the Command Status.  If the  command is completed with an 
error,
                 then the response and sense data  MUST be sent in a SCSI 
Response
                 PDU (i.e., MUST NOT be sent in a  SCSI Data packet). For 
Bidirectional
                 commands, the status MUST be  sent in a SCSI Response 
PDU.

                 ... If the command status bit is set the target MUST not 
send a SCSI
                 response PDU.

                 Examples:

                                 CommandStatusResponse=No

                 Default is Yes

                 The CommandStatusResonse is used to define the target 
implementation
                 of the data-in PDU's command status bit.  If 
CommandStatusResponse is
                 Yes then the target MUST followup a data-in PDU 
containing the command
                 status bit set with a scsi reponse PDU.  If 
CommandStatusResponse is
                 No then that target device MUST not send the scsi 
response PDU.

---

---

From: David Weibel <[email-masked]>
Date: Tue, 30 Mar 2004 08:24:51 -0700

Julian,  I found the section in SAM2 which is mandating the status only 
being sent once.  I believe this resolves our question.  We have been 
seeing a third party target returning both the S bit and SCSI response 
PDU to our initiator stack and wanted to have a solid position to 
address the issue. Thanks -David

On Mar 30, 2004, at 7:52 AM, Julian Satran wrote:

> As for your login parameter besides being far too late for such a 
> change I do not see why we should mandate this regularity when the 
> code has to be there to handle both anyhow.