RE: iSCSI: Wrapping up SendTargets

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

Mark,

Management within the transport is multiplexing functions that adds
complexity.  The selector has evolved into a discovery scheme that will
introduce non-standard interfaces for sharing a common database and will
introduce scaling problems related to primitive mechanisms afforded by
key=value prompting.  A default selector returning additional information
could be limited to serving as feedback at the user interface.  Something
along the lines of an information page pertaining only to the current
selection.  Answering "who else" does not seem wise in general.

Doug

> I don't see any reason to disallow what Marjorie is asking
> for.  However, we should also decide whether or not a SendTargets
> response may contain a well-known/default/canonical target to
> which the initiator is expected to recursively issue a
> SendTargets command.
>
> Supporting that feature is much more likely to be a problem
> if we want implementations to transition to other discovery
> mechanisms in the future, as well as creating requirements to
> avoid loops.
>
> Any thoughts?
>
> --
> Mark
>
> Black_David@emc.com wrote:
> >
> > I think Marj and I understand each other.  The issue
> > comes down to exactly this Q&A at the end of
> > Marj's previous email:
> >
> > > > David
> > > Marj
> >
> > > > Do you see a
> > > > need for a SendTargets issued to system X to
> > > > return information about system Y?
> > >
> > > No, but I see no reason to prohibit this.
> >
> > The potential reason to prohibit this is to limit the
> > use of SendTargets to having a target system describe
> > itself, which I thought was the sense of the discussion.
> > If we don't limit SendTargets to that use, it will get
> > used in the above fashion that has one target system
> > describing others.
> >
> > In my opinion, this is a decision that we get to make
> > exactly once - if we allow use of SendTargets to describe
> > other systems, we will not be able to change that at a
> > subsequent stage of the IETF standards process because
> > use of it in that fashion will be established practice
> > among multiple implementations.  This may make transitioning
> > away from SendTargets considerably more difficult.
> >
> > So, let me acknowledge Marj's position that use of SendTargets
> > to describe other systems should be allowed, and solicit
> > other comments on this issue.  In particular, I'd like to
> > hear from those who want to make sure that SendTargets
> > will be able to be retired in the future.
> >
> > Thanks,
> > --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
> > ---------------------------------------------------
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>