RE: Invalid Pdus received during Login phase

["Julian Satran" <Julian_Satran@il.ibm.com>]

OK thanks - Julo

"Robert D. Russell" <rdr@io.iol.unh.edu> 08/04/2002 12:42 AM

To:        Julian Satran <Julian_Satran@il.ibm.com>         cc:        ips@ece.cmu.edu         Subject:        RE: Invalid Pdus received during Login phase

Julian:

Some trivial typos in working draft 15 (3 August version).

1. Section 2.2.2.1, near the bottom of page 38:
        However CmdSN is as a marker ...
   should be:
        However their CmdSN is a marker ...

2. Section 2.2.6.3.2, near the bottom of page 42:
        encoded hexidecimal digits).
   should be:
        encoded hexadecimal digits).

3. Appendix C, the last example on page 252 has:
        AuthMethod:KRB5,SRP,None
   that colon should be an equal sign:
        AuthMethod=KRB5,SRP,None


Another minor point -- the paragraph in section 9.7.3 on page 156
   that contains the new wording says:

        "On incoming data, the Target Transfer Tag MUST be provided by
        the target if the A bit is set to 1.  The Target Transfer Tag
        and LUN are copied by the initiator in the SNACK of type DataACK
        that it issues as a result of receiving a SCSI Data-in PDU with
        the A bit set to 1 and MUST be set to the reserved value of
        0xffffffff otherwise."

   Of course only the TTT is set to 0xffffffff as a reserved value --
   the LUN is set to 0 when it is reserved.  Since the next paragraph
   seems to cover the necessary details about the 0xffffffff, perhaps
   we could simplify this paragraph to say:

        "On incoming data, the Target Transfer Tag and LUN MUST be
        provided by the target if the A bit is set to 1; otherwise
        they are reserved.  The Target Transfer Tag and LUN are copied
        by the initiator into the SNACK of type DataACK that it issues
        as a result of receiving a SCSI Data-in PDU with the A bit set
        to 1."


A final, less minor point -- I believe the addition of the new last
   paragraph to section 2.2.3 clearly addresses the issue of what
   the target should do when the first PDU it receives on a new TCP
   connection is not a Login request, but still leaves open what it
   should do later during the login phase if it receives a PDU other
   than a Login Request.

   The problem is the wording in the second sentence of the paragraph
   preceeding the new one:

        "Any other PDU, when received at initiator or target, is a
        protocol error and MUST result in the connection being
        terminated."

   This has two sources of misunderstanding --

   1.  It makes it sound as if an initiator can receive a Login Request
       from the target, and the target can receive a Login Response
       from the initiator, both of which are disallowed;
   2.  It makes it sound as if the target can immediately disconnect
       without first sending back a Login-Reject.

   Although the first misunderstanding can easily be resolved by
   refering to other sections of the draft, the second misunderstanding
   occurred at the plugfest.  Of course, my interpretation of its
   resolution may be incorrect, but I believe the target always needs
   to send back a Login-Reject before disconnecting, except when the
   very first PDU on a new TCP connection is not a Login (which is why
   the new paragraph was added to the end of section 2.2.3).

   If my interpretation is correct, could we eliminate the sentence
   just quoted ("Any other PDU, ... being terminated.") and instead
   add the following sentence to the end of the final (new) paragraph
   of this section:

        "Once the Login phase has started, if the target receives any
        PDU except a Login request, it MUST send a Login reject
        (with Status 0x020b) and then disconnect;  if the initiator
        receives any PDU except a Login response, it MUST immediately
        drop the connection."

   If my interpretation is not correct, we need to eliminate the
   Status code 0x020b from the table in section 9.13.5, since
   there appears to be no other use for it.  In this case there
   would also appear to be no reason to single out the first PDU
   on a new connection as being in any way different from subsequent
   PDUs during Login phase.


Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774