Re: iSCSI: Target Resets are Management Functions

["John Hufferd" <hufferd@us.ibm.com>]

It should be removed.  T10 removed it as a required function.  Management
should be done via a management interface.

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


Matt Wakeley <matt_wakeley@agilent.com>@ece.cmu.edu on 03/22/2001 02:45:54
PM

Please respond to Matt Wakeley <matt_wakeley@agilent.com>

Sent by:  owner-ips@ece.cmu.edu


To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  Re: iSCSI: Target Resets are Management Functions



John,

Are you saying that iSCSI allows the function, but does not specify how to
use
it? Or that target reset is to be removed from the list of management
functions?

John Hufferd wrote:
>
> Julian,
> Target Resets are management functions, that is where they belong, not as
> an iSCSI or SCSI action/command.  It is not like this is going to be part
> of some automatic error recovery function.  Target Resets need and
deserve
> this function as part of administration management, it is up the vendors'
> products to perform, or not, this function, with information they get (or
> not) from an Admin interaction).  I do not think we should support it in
> the normal iSCSI Protocols.  And we should not have to specify the
problem
> avoidance approaches  that the implementer SHOULD/MUST take to support
this
> function.  You will probably say that it s an implementation decision as
to
> how they avoid the problems, and that is what I am saying, and it belongs
> to the vendors' Admin function to implement or not.
>
> If it is a big enough problem for FC to take it out, with their limited
> network domain, we certainly should do that also.

The reset function is still a management function in FCP-2 (table 3), and
it's
actions are described in FCP-2, tables 4 & 5 (and elsewhere).

-Matt