iSCSI draft 02: edits/typos

[Matt Wakeley <matt_wakeley@agilent.com>]

The following are editorial changes that should be made to the iSCSI draft:

- Section 1.2.2.1, first paragraph.
"... and responses (target-to-initiator)..." should be deleted.  Responses are
covered in 1.2.2.2.

- registers vs counters: throughout the document, in places "register" is used
and in others "counter" is used when discussing the reference numbers.  I
think one should be chosen (I like "counter" better) to reduce confusion.

- Section 1.2.2.1, page 7, "command/request numbering scheme" should be just
"command numbering scheme".

- Section 1.2.5 "An initiator MUST always honor an R2T data request".  This is
not always true.  For example, if an initiator issues a command and it times
out, but the R2T arrives later, the initiator should not be required to
"honor" the R2T.

- Section 1.2.5 "If the amount of data exceeds the amount allowed for
unsolicited write data, the specific connection MUST be stalled - unsolicited
data will not be sent on this connection until the specific command has
finished sending all its data and has received a response."  This sentance is
not clear.  If the amount of unsolicited data that can be sent is negotiated
(as is specified earlier), then by definition, there is no "exceeding" of the
amount allowed.  Plus, I don't see why a connection must be "stalled" simply
because too much data is to be sent.  What if a task management command needs
to be sent to clear things up?

- Section 1.2.8 "...ensures that data can be copied to correct buffers the
first time" should be changed to "... ensures that data can be placed into the
correct buffers the first time."

- Section 2.3 should start on a new page

- Sections 2.6 and 2.7 - there is no definition of "Referenced Task Tag".

- Section 2.8: 2.8.1 defines a "Final" bit which is not shown in the header. 
Also, why is a "Final" bit required?

- Section 2.8.3:  A value of "0" is used to specify an unused Target Task
Tag.  I think a value of 0xffffffff would be better suited to indicate unused.

- Section 2.17: "An R2T MAY be answered with more than iSCSI..." should be "An
R2T MAY be answered with one or more iSCSI..."

- Section 2.19: "In host-to-communication..." needs to be fixed.

- Section 3.1: the "current" version does not match that in 2.11