RE: mailing list

[julian_satran@il.ibm.com]

To clarify the point the text in 1.2.2 reads now:

   MaxCmdSN and ExpCmdSN fields are processed as follows:

      -if the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial
      Arithmetic Sense and with a difference bounded by 2**31-1), they are
      both ignored
      -if the PDU MaxCmdSN is less than the local MaxCmdSN (in Serial
      Arithmetic Sense and with a difference bounded by 2**31-1), it is
      ignored; else it updates the local MaxCmdSN
      -if the PDU ExpCmdSN is less than the local ExpCmdSN (in Serial
      Arithmetic Sense and with a difference bounded by 2**31-1), it is
      ignored; else it updates the local ExpCmdSN


      And 2.4.9 & 2.4.10 read:

1.1.1     ExpCmdSN - Next Expected CmdSN from this Initiator

   ExpCmdSN is a Sequence Number that the target iSCSI returns to the
   initiator to acknowledge command reception. It is used to update a local
   register with the same name. An ExpCmdSN equal to MaxCmdSN+1 indicates
   that the target cannot accept new commands.

1.1.2     MaxCmdSN - Maximum CmdSN Acceptable from this Initiator

   MaxCmdSN is a Sequence Number that the target iSCSI returns to the
   initiator to indicate the maximum CmdSN the initiator can send. It is
   used to update a local register with the same name. If MaxCmdSN is equal
   to ExpCmdSN-1 that indicates to the initiator that the target can't
   receive any additional commands.  When MaxCmdSN changes at the target
   while the target has no pending PDUs to convey this information to the
   initiator it MUST generate a NOP-IN to carry the new MaxCmdSN.

   Julo

"Ayman Ghanem" <aghanem@cisco.com> on 03-07-2001 05:36:26

Please respond to "Ayman Ghanem" <aghanem@cisco.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: mailing list




Thanks Julian. Looks like the URL I put for point (1) below was not the
right one.
Here it is again about having MaxCmdSn = (ExpCmdSn - 1) as allowed value.
Any comments?.

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05088.html

Thanks.
-Ayman


> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> julian_satran@il.ibm.com
> Sent: Saturday, June 30, 2001 6:41 PM
> To: ips@ece.cmu.edu
> Subject: RE: mailing list
>
>
>
>
> No - I did not see it earlier - probably wwhen I was taken of the list...
>
> comments in text.
>
> Thanks,
> Julo
>
> "Ayman Ghanem" <aghanem@cisco.com> on 30-06-2001 23:45:13
>
> Please respond to "Ayman Ghanem" <aghanem@cisco.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:
> Subject:  RE: mailing list
>
>
>
>
> Julian,
>
> I sent this to you last week. Not sure if you got it. Also, in the Task
> Management Response, I believe the MSB of the reserved field (bit 24)
> should
> be set to 1 like other PDUs going from the target side.
>
>
> +++ fixed +++
>
> -Ayman
>
>
>
> ------------------------------------------------------------------
> ----------
>
> ------
> Julian,
>
> I have the following comments on draft-6.90:
>
> 1- I am not sure if you saw this posting, but it is not clarified in 6.90
> http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
>
> 2- I would prefer, for this draft and any future drafts, that any new
> response codes added to be assigned new values and not values assigned
> earlier to still-existing return codes. This will help backward
> compatibility with earlier drafts. For example, Task Mgt Rsp, Reject, and
> logout have responses which existed in earlier drafts but are now
> given new
> codes.
>
> ++OK (for the future and if regularity does not require otherwise) +++
>
> 3- Section 7.1, there is no reject response code for "Unsupported
Replay".
>
> +++ yes there is - code 7 - i'll make wording clearer +++
>
> 4- In sec. 4.1, version number 0x'01' should be 0x'02'
>
> +++ fixed ++++
>
> 5- Sec. 2.16.5, no Additional Runs field in the SNACK PDU
>
> +++ fixed +++
>
> 6- Bit-7 of byte 1 of the logout command should be set to 0, or
> as an F-bit
> to be consistent with text of section 2.2.2.4
>
> +++ Logout is always single and last. That is why I set the F bit to 1
+++
>
> 7- In section 2.16.1, "targets MUST support Status SNACK". However, in
> section 1.2.2.2, "To enable command recovery the target MAY
> maintain enough
> state information to enable data and status recovery after a connection
> failure". These seem to be inconsistent. Also, I could not see
> the scenario
> if the target can not support a Status SNACK request. If dropping the
> connection is the option, then I think it should be clarified.
>
> +++ the current text reads:
>
>
>    An iSCSI target that does not support recovery within connection MAY
>    discard status SNACK. If the target supports command recovery within
>    session it MAY discard the SNACK after which it MUST issue an
>    Asynchronous Message PDU with an iSCSI event indicating "Request
>    Logout".
>
>
>    ++++
> -Ayman
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > julian_satran@il.ibm.com
> > Sent: Wednesday, June 27, 2001 8:29 AM
> > To: ips@ece.cmu.edu
> > Cc: bassoon@YOGI.PDL.CMU.EDU
> > Subject: mailing list
> >
> >
> >
> >
> > Dear colleagues,
> >
> > I do not receive mail from the list (since mid last week).
> > Please address mail that you think should reach me adding me explicitly
> > until the issue is fixed.
> >
> > Regards,
> > Julo
> >
> >
> >
>
>
>
>
>