SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI Target Reset



    John,
    
    This problem remains an architectural dilemma.  We have yet to provide a
    means of establishing authority within the iSCSI domain.  Should this become
    possible, then an error reported "Not Authorized" becomes a standard way of
    excluding commands.
    
    Doug
    
    
    > This is at least better.  But I do not have the issue of it being vendor
    > unique.  This is a shut down and restart of the complete Target, and will
    > probably be part of the vendors' operator console or their own remote
    > support functions, it is not clear that it needs to be a general
    > management
    > function that works the same on all iSCSI Storage Controllers.
    >
    > Many of the major Storage Controller do not support this feature today.
    >
    > I do not believe that most SNMP implementations are very secure.  Most
    > folks do not want to have a changeable MIB until they have secure
    > SNMP, and
    > even though there is a version of SNMP that has security
    > features, this has
    > not been well supported.
    >
    > I do NOT think that Target Reset should be in the base iSCSI protocol, but
    > I think it is reasonable to hold this discussion apart from the base
    > protocol document, and the question should be asked if this is a general
    > management function or a vendor specific console or remote support
    > function.
    >
    >
    >
    > .
    > .
    > .
    > 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
    >
    >
    > "Dillard, David" <david_dillard@adaptec.com>@ece.cmu.edu on 04/22/2001
    > 08:13:49 AM
    >
    > Sent by:  owner-ips@ece.cmu.edu
    >
    >
    > To:   ips@ece.cmu.edu
    > cc:
    > Subject:  RE: Target Reset
    >
    >
    >
    > John,
    >
    > I understand the danger of issuing a target reset and I agree that it
    > should
    > not be a part of the an initiator's normal error recovery procedure.
    > However, looking at this from a management perspective I'd like to see a
    > standardized way of resetting a target.  I don't want to see a variety of
    > vendor unique methods of resetting targets sprout up.
    >
    > If resetting a target using the protocol is not desirable from your
    > perspective would incorporating this feature into the MIB be acceptable?
    > (MIBs are for management after all)
    >
    > ----------------------------------------------------------------
    > David Dillard                          david_dillard@adaptec.com
    > Management Software Group
    > Adaptec, Inc.                          www.adaptec.com
    >
    >
    >
    >
    > -----Original Message-----
    > From: John Hufferd [mailto:hufferd@us.ibm.com]
    > Sent: Sunday, April 22, 2001 4:59 AM
    > To: ips@ece.cmu.edu
    > Subject: Target Reset
    >
    >
    > 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
    >
    >
    >
    >
    
    


Home

Last updated: Tue Sep 04 01:04:56 2001
6315 messages in chronological order