iscsi: Text keys

[sandeepj@research.bell-labs.com (Sandeep Joshi)]

Julian,

Some comments on the text keys defined in Appendix E.

thanks,
-Sandeep

1) There are several text keys which have been specified
   with Use=ALL.  Such keys can be negotiated during 
   full-feature phase, which raises interesting questions
   about their effect on currently outstanding tasks.

   For example,
   a) maxOutstandingR2T : what is the effect on currently
      outstanding R2Ts ?
   b) LoginLogoutMaxTime : how does it affect connections
	  which just got dropped and need to be recovered ?
   c) DataPDULength : effect on data PDUs in flight.

   Similar questions need to be answered for practically
   all the keys which have this behaviour.  For the sake of 
   simplicity, it may be better to forbid such usage and 
   allow these keys to be only negotiated in the connection 
   or session login phase.

2) The paragraph on TargetAddress seems to indicate that one 
   or more text responses could be sent to satisfy a SendTargets 
   command.  
	 "If the list cant be delivered as a single text
	 response PDU, ..several text response PDUs can
	 be sent..logical merge of the individual lists".
   
   How does the initiator know more than one TextResponse PDUs 
   are expected for that TextCommand PDU ?  If the final bit is 
   to be used, does it imply that the initiator should keep 
   sending the sendTargets TextCommand with f=1 until it 
   receives the last TextResponse PDU ?

   Could you please clarify...

3) SendTargets again.  The ordering within the text response 
   currently is implied and needs to be specified so that 
   the initiator can correlate the target alias with the 
   target addresses.  

   Something along these lines may help
	"The order within a text response should be
	  (targetName, targetAlias(if any), list of addresses)"

4) The section on InitiatorName seems to imply that the 
   target can also propose the value for this key ??
   I presume this is a typo.
	 See "Who: Initiator and Target"