Re: iSCSI 05.txt is out

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

Hi Julian,

Draft looks good.   Here are a few issues i noticed.
Some of these issues may have been valid with 04 too.

-Sandeep 

Sec 2.7: Scsi Data for READ
---------------------------
This is a read PDU but the fields for (O|U) do not match the
corresponding positions for Read status indicators in the
Scsi Response PDU.

In the Scsi Response PDU, it is lowercase "o" and "u" which
indicate read overflow/underflow.  They are present in a
different bit positions.

Notice that the residual count position is consistent.
So how about matching up the over/underflow bits to same
positions with same lowercase syntax ?  This may also 
change the "S" bit position.

R2TDataSN
----------
Sec 6.7.1 has some new content on how to handle lost R2Ts using
SACKs.  But I noticed that the SACK request (Sec 2.16) has not
changed to indicate whether the DataSN is a R2T DataSN or just
a Read PDU DataSN (D bit)
So do we demux on the read/write operation type?
And how does this affect PDU loss in bidirectional commands ?

Sec 2.14.1
----------
CID: This field is valid only if the reason code is not "close
connection" -- you mean "close session" right ?  

To further reinforce this, can we also add "CID or reserved(0)" 
to the PDU frame above - just as we do in other cases.

Sec 2.18 Async PDU
--------------------
Could you elaborate on the scenarios proposed under which
a target might request a logout (event code=2)?  I recall this
code was added recently (in 03 or 04) but cant recall the 
exact semantics.

For example, can this code be used if some connection does not
respond to pings ?  From Sec 2.14, I see that this will result
in a Logout Command with reason_code=2 (target-requested logout).
There is also some discussion in Sec 6.7.1.2 on this.

This facility gives rise to race conditions on duplex & buffered
channels - plus the Async PDU intends to preserve the statSN
ordering.  [Async is a misnomer :-)]

Say both initiator & target decide to close a non-responding TCP
connection_1.  The initiator sends a Login (for conn recovery)
on some other connection_2.  At the same "time", the target
sends an Async PDU for c_1 on connection_3.

By the time Async PDU is delivered, the initiator may well have
recovered the connection so its going to logout a connection
which is chugging along hunky-dory.

In the absence of any synchronized timestamps, it is not possible
to know if one is responding to an event which has already
been handled.

Sec 2.10 :  Version number
----------------------------
The min & max versions are just plain numbers.  Any plans to
support major+minor version numbers ?