Re: iscsi.04 comments

[Sandeep Joshi <sandeepj@lucent.com>]

>
> 1) - quote from the 2.8.3
>
> Some basic key=value pairs are described in Appendix A & D. All these
> keys except the X- extension formatted MUST be supported by iSCSI
> initiators and targets.

oops.  missed that..

>
> 2)the WN is allways for the next - BHS by itself does not need a WN - it
> is allways the first and you know what it is and how long it is (44
> bytes)

Btw, there is a WN before the BHS in Sec 2.2 in the figure named
"Overall structure of PDU".  That caused the confusion.

Some more notes:

1) Yaron Klein pointed out that the Login Response code was wrong.
   Similar typos exist in the PDU outlines shown for many other
   target messages : Nop-In (0x80), R2T(0x90), Logout Response,
   AsyncMessage and Reject.
   These opcodes dont match with Sec 2.2.4.2

2) Sec 2.7 - typical PDU for read at byte 20 has (statSN OR reserved)
   For reads, the statSN field would always be present so reserved
   can be removed from this example.  The field is shown reserved
   in the write data PDU.

3) Have we decided/mandated which Text parameters are going to
   be connection-specific ?  I may have missed a reference to this
   in the draft.

4) Furthermore, if an existing connection (full-feature mode) is
   used for recovering a failed connection, is the initiator
   allowed to negotiate ANY list(TextCmd) parameters during the
   login restart ?

   I guess the two connections (old & new) have to be compatible
   with respect to certain parameters, otherwise command restarts
   or data PDU acks may have a problem (since maxR2T, immediateData 
   limits, etc could be different)

-Sandeep

> >
> > To:	  ips@ece.cmu.edu
> > cc:
> > Subject:  iscsi.04 comments
> >
> > Julian,
> >
> > A few questions/comments..
> >
> > 1) The following suggestion seems to be missing from
> > this draft
> > http://ips.pdl.cs.cmu.edu/mail/msg03273.html
> >
> > 2) There is a WN before the BHS and every AHS.
> > So what are the WN bits (6-4) for a BHS ?
> > Right now, there is 0=ext_cdb, 1=bidi, 2=longdata.
> > All the other values (3-7) seem to be reserved.
> >
> > 3) Section 2.17 R2T - see statement before the fig.
> > "outstanding R2T MUST be fulfilled by the initiator
> > in the order they were received".
> > Is this _within_ a command or connection or session.
> > I presume its not within a session.
> > Could you please qualify and disambiguate?
> >
> > 4) In Section 2.5 & Sec 2.6 for TaskMgmt commands the
> > RefTaskTag, if reserved, is to be set to zero.
> > In other commands (e.g. NOP-OUT), an invalid task tag is
> > indicated by 0xffffffff.  How about making it uniform
> > throughout as 0xff... (or maybe this is an oversight)
> >
> > -Sandeep
> >