Subject: iscsi.04 comments

From: Sandeep Joshi <[email-masked]>
Date: Mon, 26 Feb 2001 11:03:37 -0500

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

---

From: [email-masked]
Date: Mon, 26 Feb 2001 18:57:11 +0200

Sandeep,

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.

   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)

   3)I will qualify it with within a connection (I thought it was obvious
   but probably it is not).

   4)It is not ambiguous but I see your point - I will try to make it
   uniform (either all 0 or all 0x'ffffffff')

   Thanks,
   Julo

Sandeep Joshi <[email-masked]> on 26/02/2001 18:03:37

Please respond to Sandeep Joshi <[email-masked]>

To:   [email-masked]
cc:
Subject:  iscsi.04 comments

Julian,

-Sandeep

---

From: Sandeep Joshi <[email-masked]>
Date: Tue, 27 Feb 2001 13:08:44 -0500

> keys except the X- extension formatted MUST be supported by iSCSI

oops.  missed that..

> is allways the first and you know what it is and how long it is (44

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

---

From: Sandeep Joshi <[email-masked]>
Date: Mon, 26 Feb 2001 14:01:58 -0500

> keys except the X- extension formatted MUST be supported by iSCSI

missed that..!

> is allways the first and you know what it is and how long it is (44

the figure in sec 2.2 shows a WN before BHS.
maybe that needs to be removed ?

---

From: [email-masked]
Date: Wed, 28 Feb 2001 11:18:04 +0200

Sandeep,

comments in text - Thanks,Julo

Sandeep Joshi <[email-masked]> on 27/02/2001 20:08:44

To:   [email-masked]
cc:
Subject:  Re: iscsi.04 comments

oops.  missed that..

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:

+++ Thanks +++

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

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

   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

---

From: "Y P Cheng" <[email-masked]>
Date: Wed, 28 Feb 2001 14:49:32 -0800

I apologize if someone has already touched this topic.

I found the use of F-bit in Section 2.3 for “immediate data”  a little
confusing.  Why don’t we reserve bit 7 and use bit 4 instead and call it
I-bit.  In Section 2.4, the S-bit indicating Sense-data has similar meaning,
i.e. data field after the basic header.

Y.P., ConnectCom Solutions.