Subject: iSCSI: DLB [T.31]

From: Steve Reames <[email-masked]>
Date: Tue, 09 Jul 2002 14:33:41 -0600

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.

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 9 Jul 2002 16:05:04 -0700

Steve,

I assume you're describing the initiator perspective.  Even with the
current wording, target can ignore your status SNACK requests - 
since the error recovery support promised by the target with operational
ErrorRecoveryLevel=0 doesn't include SNACK support.  Changing 
the wording (which I believe is the right thing) wouldn't change your 
situation.

If you want to be able to selectively use the status recovery, you may
negotiate the ErrorRecoveryLevel=1 and not ever use the data recovery.
But you should be able to handle recovery R2Ts in such a case.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]