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



    
    
    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
    
    
    
    


Home

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