RE: profiles - a way to simplify iSCSI

[julian_satran@il.ibm.com]

Somesh,

You are still missing my point. Profiles are not proposed "in addition" to
what we have but instead of.
They are not meant to remove features that where introduced for a
legitimate reason or another but rather to limit
the variability in implementations and testing.

Julo

"Somesh Gupta" <someshg@yahoo.com> on 22-06-2001 21:16:33

Please respond to someshg@yahoo.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: profiles - a way to simplify iSCSI




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

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> julian_satran@il.ibm.com
> Sent: Friday, June 22, 2001 8:15 AM
> To: ips@ece.cmu.edu
> Subject: RE: profiles - a way to simplify iSCSI
>
>
>
>
> 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" <rgriswold@crossroads.com> on 22-06-2001 17:19:47
>
> Please respond to "Robert Griswold" <rgriswold@crossroads.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> 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:     julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent:     Thursday, June 21, 2001 12:15 PM
> To:  ips@ece.cmu.edu
> 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
>
>
>
>
>
>

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