RE: mailing list

[julian_satran@il.ibm.com]

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
>
>
>