iSCSI : Login Response PDU Issues.

[Santosh Rao <santoshr@cup.hp.com>]

Julian,

Some concerns regarding the Login Response PDU section of the latest
iSCSI draft :

Section 2.11.3. Login Response Status
======================================
1) Should targets use a REJECT PDU or Login Response PDU with a status
of "reject login" to indicate Login Reject ? Section 2.11.3 and 4.4
contradict
each other on this subject.

A standard REJECT PDU used to reject ALL non-scsi PDUs
[and ONLY non-scsi PDUs] would be desirable and would provide
the following benefits :

o       Allows more specific error information to be conveyed
        within SCSI Task Mgmt response PDUs and SCSI Response
        PDUs, on a reject of SCSI Task Mgmt Cmd or SCSI Command.
        (thru the Response Data for Scsi Response PDU and
         Response field for SCSI Task Mgmt response PDU).

o       Consistent with Fibre Channel semantics for the standard
         LS_RJT for all ELS'. This also allows for easy mapping
         from iSCSI Response PDUs to FC ELS responses and vice versa
         in iSCSI-FC bridges.
         (since an iSCSI-FC bridge would be mapping certain types of
         operations and their responses from one protocol to another
like
          Login. Logout, NOP-OUT, etc.)

o        REJECT field in the Login Response PDU can be made reserved.

2) Whatever the mechanism that will be finally used for login rejection
[be it the REJECT PDU or "reject login" in login response PDU], it
should
make provisions for detailed reason codes and reason explanations that
allow
the initiator to determine the cause of the rejection. This does not
currently exist in the draft.

3) Quoting from the draft :

"In the case that the Status is reject login the initiator should
immediately
close down its end of the TCP connection, thus freeing up the target's
port for some other connection."

On a REJECT, initiators may wish to retry Login. [perhaps, with a
modification to their Login Command PDU or TEXT parameters .

Perhaps, the word "may" might be a better fit instead of "should" here.

Thanks,
Santosh
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard