iSCSI: draft04 questions

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

Thanks for incorporating a lot of the earlier reflector feedback 
into the latest draft.

Some questions:

1. Section 1.2.5 states :
	"Unsolicited data MUST be sent on every connection in the 
	same order in which commands were sent. If the amount of data 
	exceeds the amount allowed for unsolicited write data, the 
	specific connection MUST be stalled - i.e., no more unsolicited 
	data will be sent on this connection until the specific command 
	has finished sending all its data and has received a response."

Sorry if there was a discussion on this already.  Why not the iSCSI 
response of "Unsolicited data rejected" usable for this case?  Initiator
appears to be behaving erratically, and I don't see how it is expected
to adhere to the stipulation that it shall not send anymore unsolicited
data till this command is completed.

2. I didn't find a way for an iSCSI target to say that it does not support 
any unsolicited data at all.  SPC-2 specifies that a zero FirstBurstSize
means unlimited.

3. Section 2.14 states: 
	"If an initiator intends to start recovery for a failing connection it
   	MUST use the either the Logout command to "clean-up" the target end
   	of a failing connection and enable recovery to start, or use the
   	restart option of the Login command to the same effect."
This seems to be contradicting section 2.10.1, where a prior logout of the
CID is stated as a requirement for using the restart bit of the Login PDU
(which I agree with).


4. Somehow, "Asynchronous Message" seems at odds with the rest of the
usage in the draft in regards to PDUs (since a message is introduced as
PDU in section 1.2).  Should we may be just call it an AEN PDU?  Section
2.14.3 calls this so.  (I realize that it may not always result in a 
SCSI-level AER.)

5. In the same section 2.18, I dont' quite see the operational difference
for an initiator, if any, between iSCSI event codes 2 & 3.  Could you please
comment?  

Also, isn't the time in seconds the maximum time than the minimum
time as currently stated? 

6. In section 2.20.1, reject reason code 5 is stated as a "command 
restart reject".  Seems like the usage of "restart" in the draft elsewhere
is for the connection/session login, and "retry" is for commands -
except this one.  Comment if I am reading too much into the usage.

7. Section 6.2 on digest errors states:
	"If the error is a Data-Digest-Error in a Data-PDU, the target 
	MUST either request retransmission with a R2T or answer with 
	a Reject iSCSI PDU and abort the task."
Were you meaning the target's internal termination of the task? That
could cause problems on a subsequent Data PDU reception from the 
initiator since there may be no state for the task in the target.  
Suggest dropping "and abort the task".

8. Same section states the following:  
	"When an initiator receives an iSCSI data PDU with a Data-Digest
   	error, it must discard the PDU and it MUST either request the missing
   	data PDUs through SACK or terminate the command with an error."
If you meant reporting a service failure to SCSI within the initiator, 
seems like that could cause trouble to initiator iSCSI layer since it 
is likely to receive the data/status PDUs for the command shortly thereafter.
Suggest dropping "or terminate the command with an error", or replace
with "or abort the task".

9. End of section 6.7.1 states:
	"An iSCSI target MAY reject a data-SACK and terminate the command with
   	an iSCSI error response of SACK rejected."

The "SACK rejected" iSCSI response code needs to be added in section 2.4.2.

Thanks.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com