|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI Target ResetJohn, 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 |