RE: iSCSI : login keys & mode page settings

[Santosh Rao <santoshr@cup.hp.com>]

David,

Apologies for the late response on this. I was hoping we could complete this
thread of discussion at Nashua, but for lack of time, we are back on the list.

Regarding your question below :

> If one Initiator can damage another in this fashion, then we
> may indeed have a problem.

> Comments?,

Shared mode page implementations in targets is quite common and modification of
control parameters through a mode select would indeed affect all other
initiators logged into the target. This is not desirable behaviour and iSCSI
may be better served using login/text based key negotiation rather than the
mode select mechanisms which opens it up to the side effects of affecting all
connected initiators.

Thanks,
Santosh


------------------------------------------------------------------------
Subject: RE: iSCSI : login keys & mode page settings 
From: Black_David@emc.com 
Date: Fri, 20 Apr 2001 20:32:17 -0400 
Cc: ips@ece.cmu.edu 

I'm not sure -- this sounds somewhat like the
old principle of not asking why there's a hole
in one's foot when one has aimed the gun at
it and pulled the trigger.  For the tape
example, if some tape driver changes a
Target iSCSI parameter that disrupts that
driver's own tape I/O in a fashion that the
driver can't recover from, I think it's
clear where the fault lies.  If one Initiator
can damage another in this fashion, then we
may indeed have a problem.

Comments?,
--David

> -----Original Message-----
> From: Santosh Rao [SMTP:santoshr@cup.hp.com]
> Sent: Friday, April 20, 2001 8:09 PM
> To:   Black_David@emc.com
> Cc:   ips@ece.cmu.edu
> Subject:      Re: iSCSI : login keys & mode page settings
> 
> David,
> 
> Some clarification on the basis for classifying login
ould
> also be helpful. Should login keys that can disrupt
> I/O on their change
> be allowed to be non-LO ?
> 
> Thanks,
> Santosh
> 
> Black_David@emc.com wrote:
> > 
> > Without getting into the technical details of the
> > discussion, I have a couple of observations:
> > 
> > (A) The issue of whether to allow mode page
> >         access to and modification of iSCSI
ers
> >         will need to be taken up at the interim
> >         meeting.  IMHO, access seems like a good
> >         idea, so that SCSI-generic code that doesn't
> >         know specifically about iSCSI can find
> >         what it expects where it expects it, but
> >         I'm unsure about modification because it
> >         may carry a risk of code that's
naware
> >         getting something wrong.  The mode page
> >         commands should be transparent to iSCSI.
> > 
> > (B) The mode page and text key mechanisms have
> >         to access the same data.  Section 3 of the
> >         -06 version says this, but needs some
> > 	   editing
> >         to enforce it by using "MUST" or its
> > 	   equivalent
> >         (cf. RFC 2119).  This is to prevent an
> >         implementation from having two instances of
> >         the same parameter - one for the mode page and
> >         one for the text keys - which would be a bad
> >         thing.
> > 
> > --David

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
#################################