Re: iSCSI : login keys & mode page settings

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

Black_David@emc.com wrote:

> (1) Is changing an iSCSI key allowed to cause
>         problems for other initiators?

No.

> (2) Does the iSCSI key mechanism have to behave
>         identically to the corresponding mode
>         page mechanism.

No. 

Better still, the mode page mechanism can be dis-allowed [or strongly
discouraged] by iSCSI, allowing only 1 mechanism for setting these
options, which is through the use of login keys.

Something to the effect of :
"Initiators SHOULD [MUST ?] NOT use Mode Select to modify these contol
options and any key negotiation SHOULD [MUST ?] be done through
login/text keys" 

may help address these concerns.

Thanks,
Santosh



> 
> 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
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard