Subject: Re: iSCSI 4.1 & 4.2

From: "Julian Satran" <[email-masked]>
Date: Wed, 8 May 2002 22:49:41 +0300

Your messages have a certain level of inconsistency.
On one of them you state the last call is meant to get us rid of bugs (you
must have a experienced a large set of last calls state this with such
confidence) and here you ask for a change for something that is certainly
not a bug.

Julo

|---------+---------------------------->
|         |           Paul Koning      |
|         |           <[email-masked]>  |
|         |           Sent by:         |
|         |           [email-masked]|
|         |           .edu             |
|         |                            |
|         |                            |
|         |           04/29/2002 09:08 |
|         |           PM               |
|         |           Please respond to|
|         |           Paul Koning      |
|         |                            |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------|
  |                                                                                                               |
  |       To:       [email-masked]                                                                               |
  |       cc:       [email-masked]                                                                               |
  |       Subject:  Re: iSCSI 4.1 & 4.2                                                                           |
  |                                                                                                               |
  |                                                                                                               |
  >---------------------------------------------------------------------------------------------------------------|

Excerpt of message (sent 29 April 2002) by Mallikarjun C.:
> > Specifically, the two cases in which responses are OPTIONAL are:
>
> I would strongly recommend getting rid of this special case.

Yes, that would be good riddance for unnecessary confusion and special
case extra work in implementations.  We've discussed this before;
nothing changed then, even though, as far as I remember, not a single
person spoke up in favor of the current special cases.

       paul

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 9 May 2002 09:44:43 -0400 (EDT)

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
[email-masked]
603-862-3774