Subject: RE: profiles - a way to simplify iSCSI

From: [email-masked]
Date: Fri, 22 Jun 2001 18:15:19 +0300

Robert,

Profiles are meant INSTEAD -OF not in addition to the current set of
features.
I appreciate your concerns but I think that I must have misstated the
profile intention.
A profile will be an exact mapping of a set of functions we have today.
As such it will be SIMPLER both to implement and test.

Julo

"Robert Griswold" <[email-masked]> on 22-06-2001 17:19:47

Please respond to "Robert Griswold" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  RE: profiles - a way to simplify iSCSI

Julian:

Well, drawing on my experience from the consumer storage specs
(ATA/ATAPI/MMC), profiles and features lead to huge interoperability
problems.  The issue for robust (full featured) targets and initiators
is they have to chase down every single interpretation of feature sets,
some that they don't even care about, so the devices are not caught in
transport or command sequences they have no idea about.  I am in
agreement with David Black and others who have specified that the iSCSI
transport needs simplicity rather than complexity; I fear that providing
still more optional implementations would lead to more problems.  If we
believe the hype from the press, then iSCSI will make for cheap targets,
which means fast product schedules and low engineering and test coverage
from companies that could ship millions of little iSCSI boxes.  A
tighter iSCSI specification might help keep some of these potential
interoperability problems from becoming wildfires.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     [email-masked] [mailto:[email-masked]]
Sent:     Thursday, June 21, 2001 12:15 PM
To:  [email-masked]
Subject:  profiles - a way to simplify iSCSI

Dear colleagues,

iSCSI keeps getting richer in negotiable parameters/features.
Although flexibility is a great thing every new negotiable
parameter/feature get us all worrying about:

   what it will break when used in combination with other
   parameters/features
   how are we going to test that all our combinations work as we think
that
   they are specified
   are we understanding/specifying the combinations the same way as
anybody
   else

I assume that many of you are wondering, as I do, if all this
flexibility
is really worth it's price.
Would the community not be better served by specifying profiles that are
a
complete-and-invariable combination of features and very small set of
numerical parameters?

I would start with 2 profiles:

   the minimal profile (only basic features)
   the maximum profile (all the features)

and then (only if we are strongly convinced it is needed) add a middle
point.

Please comment,
Julo

---

From: "Somesh Gupta" <[email-masked]>
Date: Fri, 22 Jun 2001 11:16:33 -0700

Julian,

I think a number of our colleagues are speaking about the
complexity of the spec as it stands today and the need
to reduce the complexity.

As I said, if a reasonable profile gets agreed upon (I apologise
in advance but I have not seen the ability to say no to feature
creep here), then that will become the de-facto standard. And
everything else will be an appendage.

We might as well do that to start with.

It is much better to do that, and as Steph suggested, add
features that are required in a newer rev of the spec. It is
not as if standards don't evolve.

John Vrabel's message indicates a very good starting point
for pruning the spec (I disagree on the asynch messages).

Somesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, June 22, 2001 8:15 AM
> To: [email-masked]

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com