Re: iSCSI: Login questions

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

Julian,

I now see that there is more discussion of Login phase towards
the end of the draft answering some of my questions below.  So, here
are my latest comments.  (Sorry, should have waited posting till
I read through the end..). 

o Section 6.3 allows for parameter negotiation to be skipped where
  it may be appropriate.  I like this and recommend that it be 
  added as one of the reasons why a Login Response may be returned
  directly, in Section 3.1 (Currently, it gives the lack of target 
  support for negotiation as the only reason this can happen).
  
o I suggest intermediate Text Response PDU to be instead a Login
  Response PDU with "conditional success" status.  It appears to
  me that it is cleaner to enforce uniform command->response expectations 
  on either end this way.
  
o Editorial: Sections 1.2.3 through 1.2.4 discuss login process
  in detail.  Section 3 does the same towards the end, and Section
  6.3 does some more before the end of the draft.  Suggest somehow 
  merging these into a contiguous list of sections.

Thanks.
--
Mallikarjun 


Mallikarjun Chadalapaka
M/S 5601			
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard, Roseville.
cbm@rose.hp.com


>Julian,
>
>The current iSCSI draft allows for sending the Text commands 
>associated with Login to be sent in a separate Text Command 
>PDU on the same Initiator Task Tag. 
>
>1.There doesn't appear to be a way for a target to know that 
>  there's a Text command PDU coming in as part of the login 
>  process.  It is currently spec'ed in a way a target might 
>  send a Login Response before it sees the Text Command PDU.
>
>  I suggest creating a "T-bit" in the Login PDU for this, on 
>  seeing which the target waits for the Text Command and sends 
>  a Login Response PDU only after dealing with it.  
>
>2.Once we do the above, it appears to me that we can do away with
>  concurrent use of the same Initiator Task Tag for Login and Text
>  command PDUs.  This results in cleaner iSCSI implementations.
>
>3.Please clarify if a target can send a Text Response PDU for 
>  the text commands contained in a Login PDU.  I assume it is not
>  the case - target has to send Response PDUs only for the commands
>  that it received (Login/Text).  
>
>  This is the sentence in Section 2.8.2 which makes me ask this 
>  question:
>  "The Initiator Task Tag matches the tag used in the initial Text
>  Command or the Login Initiator Task Tag."  
>
>  Suggest dropping the phrase "or....", if my interpretation is true.
>  
>4.Editorial: suggest using "identifier" instead of "tag" in Section
>  2.10.4, sentence 1 - "The TSID is an initiator identifying tag set
>  by the target".
>
>Thanks.
>--
>Mallikarjun 
>
>
>Mallikarjun Chadalapaka
>M/S 5601			
>Networked Storage Architecture
>Network Storage Solutions Organization
>Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>