Subject: RE: iSCSI: Wrapping up SendTargets

From: [email-masked]
Date: Mon, 25 Jun 2001 20:41:51 -0400

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Mark Bakke <[email-masked]>
Date: Tue, 26 Jun 2001 15:37:44 -0500

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

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 26 Jun 2001 15:27:11 -0700

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

---

From: Glen Turner <[email-masked]>
Date: Wed, 27 Jun 2001 11:17:55 +0930

Mark Bakke wrote:
> for...

There's the question of seperation of control and data.
My reading is that the spec to date assumes that these
will be in the same host.

Given the increasing complexity of the control services,
I'm not sure that a disk CPU can economically meet
the control requirements (I'm not a disk CPU expert).

So the argument for SendTargets describing other
targets it to allow a host that handles only control
services (such as a daemon on a general-purpose CPU).

Allowing a seperation also simplifies the firewalling
task.

I need to go and have a close read of the spec from
this perspective so please regard the above as a
very tentative remark, made very late in the day,
whilst reaching for the asbestos underwear :-)

Regards,
Glen

-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 [email-masked]          http://www.aarnet.edu.au/

---

From: Mark Bakke <[email-masked]>
Date: Fri, 29 Jun 2001 11:26:40 -0500

Glen-

I think that this is at least partially the sort of
thing Marjorie had in mind.  I strongly agree, and
given Jim's comments (in a later email; I've been away),
there's no way for someone "outside" to really know
whether an implementation is returning targets for one
or more "boxes" anyway.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054