RE: iSCSI: DLB [T.31]

[Black_David@emc.com]

We'll need to discuss this in Yokohama, as there seems to be

a difference of opinion about whether this sort of

"ErrorRecoveryLevel 0.5" is allowed.  --David

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, July 14, 2002 4:09 AM
To: Steve Reames
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: DLB [T.31]

The whole text is meant only to show what the normative behavior will be at ErrorRecoveryLevel=1 It does not preclude you doing partial recovery
and not raising at level 1 although most of your partners are bound to assume the worst and ignore your efforts.

Julo

Steve Reames <reames@diskdrive.com> Sent by: owner-ips@ece.cmu.edu 07/09/2002 11:33 PM Please respond to Steve Reames

To:        ips@ece.cmu.edu         cc:                 Subject:        iSCSI: DLB [T.31]

 From DLB's comments:

>[T.31] 9.16.1  Type
>
>   An iSCSI target that does not support recovery within connection MAY
>   reject the status SNACK with a Reject PDU. If the target supports
>   recovery within connection, it MAY reject the SNACK after which it
>   MUST issue an Asynchronous Message PDU with an iSCSI event that indi-
>   cates "Request Logout".
>
> This should be conditioned on the operational ErrorRecoveryLevel of the
> session, not whether the target supports recovery within connection.

I would prefer that this not be conditioned on the ErrorRecoveryLevel. If I
am writing code, I may choose to support recovery-within-connection, but
not all the features that would be required to move me up to
ErrorRecoveryLevel 1. I would like SNACK and Reject PDUs to work properly
for my code, even though it is technically only "ErrorRecoveryLevel 0.5".
                As I read it, changing the wording would allow the target to ignore my
improved error recovery efforts unless I have a full ErrorRecoveryLevel 1
implementation. David, I doubt that is what you intended, so maybe you want
to word it a little differently.