RE: iSCSI:Target Reset

[julian_satran@il.ibm.com]

It looks close to a decent solution. As we are still trying to minimize
options we may want to specify a response code telling that the result was
"good" but no reset was really done (except for authorized users)
This will satisfy legacy software and will avoid the harm John is so
concerned about and avoid adding an option.

I said already on this list that removing it is really a bad idea as any
management program will need probably full access to the SCSI command set.

Julo

Black_David@emc.com on 23/04/2001 18:19:29

Please respond to Black_David@emc.com

To:   John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI:Target Reset




With my co-chair hat off, my inclination would be to
specify it (since it's in SAM) but include words about
the risks, make support for it OPTIONAL, and point out
that implementations may want to have access controls
on which initiators are permitted to do this.  I'm
assuming that at least two implementations will do
this so that we don't get into that issues of potentially
needing to remove this in order to go from Proposed
Standard to Draft Standard in the future.

--David

> -----Original Message-----
> From:   John Hufferd [SMTP:hufferd@us.ibm.com]
> Sent:   Sunday, April 22, 2001 5:52 PM
> To:     ips@ece.cmu.edu
> Subject:     iSCSI:Target Reset
>
> (resend of message with iSCSI in Subject)
> I thought we had a number of discussion previously about Target Reset
> (Warm
> or Cold).  I thought there was general feeling that this command is so
> dangerous that it should not be supported by iSCSI.  The long distance
> capability of iSCSI makes the risks involved unmanageable.  There should
> only be an Admin way to do this.
>
> Some folks have said that we could permit it and have special
> authorization
> etc.  This would probably cause a separate section in the spec. to define
> the authorization approach,  and what ever other security is needed to
> prevent this from inappropriately being used.  All for what purpose?
This
> can not be part of error recovery from a normal initiator.  The wide
> spread
> effect is too great for that.
>
> I would like to hear from the list about their feeling on this item.
>
>
>
> .
> .
> .
> 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: hufferd@us.ibm.com