RE: iSCSI : login keys & mode page settings

[Black_David@emc.com]

Hmm ... I'm quite capable of talking myself around
in a circle on this one because there are two issues
mixed in here:

(1) Is changing an iSCSI key allowed to cause
	problems for other initiators?
(2) Does the iSCSI key mechanism have to behave
	identically to the corresponding mode
	page mechanism.

Given the need to support old systems that may
get (1) wrong (mode page sets can damage other
initiators), the best we may be able to do on it
is a SHOULD:
(1) SHOULD not share key values among sessions
	(i.e., setting of a key value in one session
	SHOULD NOT affect the setting in any other
	session.
On (2), how about
- When a key refers to a mode page entry, the
	underlying value MUST be shared between
	the mode page and the key in an iSCSI session
	(e.g., a value set by a text key MUST be
	retrieved by the mode page if the implementation
	accepted the value).
- Restrictions on value changes in full-feature
	mode SHOULD (MUST?) match when a value is
	shared between a text key and a mode page
	entry.

Comments?

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From:	Santosh Rao [SMTP:santoshr@cup.hp.com]
> Sent:	Friday, May 04, 2001 2:15 PM
> To:	Black_David@emc.com; ips@ece.cmu.edu
> Subject:	RE: iSCSI : login keys & mode page settings
> 
> 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
> #################################