RE: iSCSI : login keys & mode page settings

["Douglas Otis" <dotis@sanlight.net>]

Bob,

There is a problem of scope with the present iSCSI specifications.  In my
view, there should be a document that defines the "iSCSI device", and others
that define transport.  The "iSCSI device" should be a T10 document.  The
difficulty results from the amalgam two separate goals.  Much of the
compatibility issues will hinge on the device behavior model, and mode page
definitions.  The iSCSI device will be expected to handle more of the
functionality of that found in the typical wedge driver.  None of these
issues are directly relevant to transport.

Doug

Robert Snively wrote:

Be deprecating the mode page mechanism, you would reduce the
compatibility with present management software, but more
importantly, you would increase the complexity of many devices
that would still have to interpret the somewhat obscure intent
of a key in terms of a mode page action that would have to be
executed against an actual SCSI device.
For compatibility, the natural method to prohibit would be
the new and therefore incompatible method.

Bob
>  -----Original Message-----
>  From: Santosh Rao [mailto:santoshr@cup.hp.com]
>  Sent: Tuesday, May 08, 2001 5:37 PM
>  To: Black_David@emc.com
>  Cc: ips@ece.cmu.edu
>  Subject: Re: iSCSI : login keys & mode page settings
>
>
>  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
>