Re: iSCSI: NOP-In

["Julian Satran" <Julian_Satran@il.ibm.com>]

OK - thanks - Julo

"Robert D. Russell" <rdr@io.iol.unh.edu> 05/09/2002 04:44 PM Please respond to "Robert D. Russell"

To:        Julian Satran/Haifa/IBM@IBMIL         cc:        ips@ece.cmu.edu, <owner-ips@ece.cmu.edu>         Subject:        iSCSI: NOP-In

Julian:

A request for two small changes in wording in draft 12:

1) The last paragraph of section 9.19 says:

  "When a target sends a NOP-In as a "ping" (the Initiator
  Task Tag is 0xffffffff) it MUST NOT send any data in the
  data segment (DataSegmentLength MUST be 0)."

I believe this should be restated to read simply:

  "When a target sends a NOP-In with an Initiator Task Tag
  value of 0xffffffff, it MUST NOT send any data in the data
  segment (DataSegmentLength MUST be 0)."

The reason for this change is that the Initiator Task Tag can
also be 0xffffffff when the target sends a NOP-In "as a means
to carry a changed ExpCmdSN and/or MaxCmdSN".  This is not a
"ping", but I believe there should not be any data in the data
segment for this case either.


2) For the same reason, I believe the last paragraph of section
9.19.1, which now reads:

  "Whenever the NOP-In is sent as a "ping" to an initiator (not as
  a response to a NOP-Out), the StatSN field will contain the next
  StatSN.  However, StatSN for this connection is not advanced."

should be changed to read:

  "The NOP-In always contains a valid StatSN field.  However,
  when the NOP-In is sent with an Initiator Task Tag value of
  0xffffffff, the StatSN field is not advanced."

If this change is not made, it is unclear whether or not to advance
the StatSN field when the target sends a NOP-In "as a means
to carry a changed ExpCmdSN and/or MaxCmdSN".  I believe this case
should be treated the same as when the target sends a NOP-In as a
"ping".

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774