Re: iscsi.04 comments

[julian_satran@il.ibm.com]

Sandeep,

comments in text - Thanks,Julo

Sandeep Joshi <sandeepj@lucent.com> on 27/02/2001 20:08:44

Please respond to Sandeep Joshi <sandeepj@lucent.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iscsi.04 comments




>
> 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.
+++ The WN before BHS refers to the next - as BHS is always there and is
fixed in length +++
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
+++ Thanks +++
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.

+++ No StatSN is set only if the S bit is 1. I will specify.

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.

+++ I would say that some are and some not. Out of thoseoutlined
only the Markers are connection specific. I will add this - thanks. +++

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)
+++There is a statement saying that only the leading connection can do this
- I'll make
it more specific as it relates to renegotiation also+++

-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
> >