iSCSI: comments

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

I know that you're close to publishing rev07, but here
are some belated comments (sorry!) on rev06.  Thanks.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com




- Suggest making the following para from section 1.1 as the second 
  para in section 1.2 - since "iSCSI" hasn't even been defined
  in its current context.

         For performance reasons, iSCSI allows a
         "phase-collapse" (e.g., command and its associated data may be
         shipped together from initiator to target and data and responses may
         be shipped together from targets).

- Suggest dropping the sentence " The numbering is session-wide."
  in section 1.2.2.1 since that's repeating the same from six paras
  earlier.

- Suggest substituting the following in 1.2.2.1

         Once the device serving part of the target SCSI has received a
         command, CmdSN ceases to be significant.

  with
         Once the iSCSI command PDU is considered eligible for execution
         either by the device serving part of the target SCSI or the 
         target iSCSI layer itself, CmdSN ceases to be significant.

- Suggest dropping the following from 1.2.2.1 since it is describing
  possibly implementation notes which are covered in section 7.3.
  Referring to section 7.3 for further discussion would be appropriate.

         iSCSI may avoid delivering some command to the
         SCSI layer if so required by some prior SCSI or iSCSI action (e.g.,
         clear task set Task Management request received before all the
         commands it was supposed to act on).

- Suggest moving the following last para from section 1.2.5 

         Each iSCSI session to a target is treated as if it originated 
         from a different and logically independent initiator.

  into the second para on 1.2.3, and drop the following text in there.

         If an initiator and target are connected through more than one 
         session, both the initiator and target perceive the other as 
         a different entity on each session (a different I_T nexus in 
         SAM-2 parlance).

- Suggest changing the SHOULD to MAY in the following sentence in 1.2.4
  in view of scope for d-o-s attacks.
         At the target, closing the connection SHOULD be preceded by a 
         Reject PDU sent to the initiator.

- Suggest adding the phrase 
         "and when the connection is not in the full-feature phase"

  at the end to the following sentence in 1.2.6

         Graceful connection shutdowns MUST only occur when there are no
         outstanding tasks that have allegiance to the connection.

- Suggest substituting "PDUs" with "opcode types" in the following sentence
  in 2.2.2.4 -
         These fields have different meanings for different PDUs.

- Suggest additionally qualifying the following in 2.3.4 -
         If the command is a retry (the X bit is 1) this field will contain....

  to
         If the command is a retry (the X bit is 1) establishing a new
         connection allegiance, this field will contain....

- Suggest replacing the following sentence fragment in 2.4.8 -
         For responses sent because of retry the StatSN used MUST be the same...
  
  with
         For responses sent due to retransmission requests, the StatSN used 
         MUST be the same....

  since I don't think even replaying (ERT terminology) a command 
  would result in the same StatSN/CmdSN.