Subject: iscsi: rev 05 - section 2.5.1 is incomplete

From: Ralph Weber <[email-masked]>
Date: Mon, 12 Mar 2001 22:09:08 -0600

The following statement is only half true:

   For the <Clear Task Set>, if the SCSI control mode
   enables AE reporting, the target MUST send an
   Asynchronous Event to all other attached initiators
   to inform them that all pending tasks are cancelled.

If the SCSI control mode [page] does not enable AE
reporting, then the target MUST establish a unit
attention condition for all other attached initiators.

In fact, the target must establish a unit attention
condition regardless of the contents of the SCSI
control mode page.  At this is specified in SAM-2.
What the control mode pages does is tell the target
how to report that unit attention condition; via
a Check Condition on the next command received, or
via an asynchronous event report.

Someone might read the iSCSI version 05 text as
releasing them from the SAM-2 requirement, which
I doubt will be helpful to the SCSI community
at large.

The same problem exists in the following 2.5.1
text:

   For the <Target Warm Reset> and <Target Cold Reset>
   functions, the target cancels all pending operations
   and are both equivalent to the Target Reset as
   specified by SAM-2.  Provided that SCSI control mode
   enables AE reporting, the target MUST send an
   Asynchronous Event to all attached initiators
   notifying them that the target is being reset.

FYI

Ralph...

---

From: [email-masked]
Date: Tue, 13 Mar 2001 09:31:08 +0200

Will fix.

It should read:

   For the <Clear Task Set>, the target MUST enter a Unit Attention
   Condition for all other attached initiators to inform them that all
   pending tasks are cancelled. After reporting the Unit Attention
   Condition the target MUST enter the ACA state for any initiator for
   which it had pending tasks.

   For the <Target Warm Reset> and <Target Cold Reset> functions, the
   target cancels all pending operations and are both equivalent to the
   Target Reset as specified by SAM-2.  The target MUST enter a Unit
   Attention Condition for all attached initiators notifying them that the
   target is being reset.

   In addition, for the <Target Warm Reset>, after reporting the Unit
   Attention Condition, the target enters the ACA state on all sessions and
   all LUs on which the condition was reported.

   In addition, for the <Target Cold Reset> the target then MUST terminate
   all of its TCP connections to all initiators (all sessions are
   terminated). However, if the target finds that it cannot send the
   required response or AEN, it MUST continue the reset operation and it
   SHOULD log the condition for later retrieval. The logging operation MUST
   be reported through the target MIB.

   Further actions on reset functions are specified in the relevant SCSI
   documents for the specific class of devices.

   Thanks,
   Julo

Ralph Weber <[email-masked]> on 13/03/2001 06:09:08

Please respond to [email-masked]

To:   IPS Reflector <[email-masked]>
cc:
Subject:  iscsi: rev 05 - section 2.5.1 is incomplete

FYI

Ralph...

---

From: "John Hufferd" <[email-masked]>
Date: Tue, 13 Mar 2001 02:18:54 -0800

Julian,
based on the response that we got from Robert Elliott @ Compaq,  we should
probably at least change the draft to  remove the Target Reset (Target Warm
Reset and Target Cold Reset).  This is good news, since these things would
have been to much of a problem for iSCSI to permit.  I do not really like
the Logical Unit Resets either, but at least it should only effect the
device you have a right to use, so the impact is a lot less of a problem
there, and I think we can live with that.

Rober said:
Today, T10 approved 01-015r2.  For devices compliant with SAM-2 revision
16,
Logical Unit Reset is now mandatory and Target Reset is not.  Protocols are
allowed to mandate Target Reset, make it optional, or not support it at
all.

In response, the SCSI RDMA protocol working group (defining SCSI over
InfiniBand) voted to remove Target Reset support from that protocol.  See
T10 document 01-108r0 for the (short) proposal.

I recommend you do the same and remove both Target Warm Reset and Target
Cold Reset task management functions from iSCSI.

Other IP protocols don't offer similar resets - a web browser doesn't have
a
way to reset an http server, a NFS client cannot reset an NFS server, a
telnet user cannot interfere with other telnet users.  iSCSI shouldn't be
any different.

John's email mentioned 4 task management functions, which included Logical
Unit Reset, and Clear Task Set.  The Access Controls feature (by Jim
Hafner;
going into SPC-3 revision 1) can be used to prevent initiators from logging
in and issuing Logical Unit Reset and Clear Task Set. ....
---
[email-masked]
Compaq Server Storage

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 03/12/2001 11:31:08 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iscsi: rev 05 - section 2.5.1 is incomplete

Will fix.

It should read:

   Thanks,
   Julo

FYI

Ralph...

---

From: [email-masked]
Date: Tue, 13 Mar 2001 14:27:19 +0200

John,

I respectfully disagree (and I said so in the T10 meeting too).  There are
better ways to protect against Target Reset
than to remove it from your command set. The Target Reset allows you to
clean atomically all your LUs.
If you are afraid about mistakes by unauthorized initiators we can leave it
to the target to reject the command
for unauthorized initiators.  To obtain the same effect without Target
Reset you will have to do a sequence of operations including a reservation
for all the units and that might not work out.

I bet that they will end-up having to put the same function back through
some management interface (SNMP?)
and then have to deal with the synchronization.

I suggest we leave the commands in and invent a reject-response for
initiators we don't want to allow them to do it based on the authentication
and/or accessId.

Regards,
Julo

John Hufferd@IBMUS
13/03/2001 12:18

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
From: John Hufferd/San Jose/IBM@IBMUS
Subject:  Re: iscsi: rev 05 - section 2.5.1 is incomplete  (Document link:
      Julian Satran - Mail)

Julian,

Rober said:

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Will fix.

It should read:

   Thanks,
   Julo

FYI

Ralph...

---

From: "Jim Hafner" <[email-masked]>
Date: Tue, 13 Mar 2001 07:55:22 -0800

Julo,

You raise an interesting perspective on the desire to have an atomic target
reset and to scope the use of that function to authorized initiators.
Unfortunately, there isn't any way in either SAM or Access Controls to
define the "initiators we don't want to allow...based on the authentication
and/or accessId".  Access controls grant access to a device and a subset of
logical units.  There is no "level of authority" that allows the target to
distinguish a management entity from a non-management entity for any SAM
task management function.   SAM has no such notions.  iSCSI could define
such notions, but then why must the action be SAM's Target Reset (see
"approaches" below).

Also, I wasn't aware that a reservation was required to do a logical unit
reset.

Here's my perspective.
1) In the multi-initiator environments, the Target Reset type function
(warm or cold) should be handled through management interfaces, not by any
host with access to a part of the device.  In fact, ANYTHING that impacts
non-clustered/non-cooperating initiators in unsuspecting ways ought to have
this property; this includes anything that smacks of management action.
2) There are many reasons for such a function (for example, to clear
networking interfaces for the device, reboot, etc.), but it should NOT be
just to clear task sets; it should be done with extreme care and by an
entity that sees the "bigger picture".
3) The overhead of iterating a set of individual logical unit resets to
clear task sets is minimal compared to the ill effects more global actions
might have on other initiators.

In short, I support disallowing Target Reset in iSCSI.

If you want a "managed" form of this action, I see three approaches:
a) define it as a iSCSI function (not a SAM function) and scope the rules
on who/what/when/where/why.  That's a big rat hole and is what you suggest
will be required somewhere.
b) define it as a SCSI Access Controls service action requiring the
management key.
c) leave it to the vendor-specific management interfaces.
In all cases however, the function is NOT SAM's Target Reset Task
Management.

Jim Hafner

Julian Satran/Haifa/IBM@[email-masked] on 03-13-2001 04:27:19 AM

To:   [email-masked]
cc:

John,

Regards,
Julo

John Hufferd@IBMUS
13/03/2001 12:18

Julian,

Rober said:

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Will fix.

It should read:

   Thanks,
   Julo

FYI

Ralph...