RE: profiles - a way to simplify iSCSI

["Robert Griswold" <rgriswold@Crossroads.com>]

Julo:

That is exactly what the MMC and ATA/ATAPI specifications do, the
declare the basics; options and required, then group them into
functional profiles or feature sets.  Setting off minimums, maximums and
middle ranges will create classes and sub-classes of implementations.
This will force those who don't create end-node targets to have deep
understandings of problems associated with feature set
misinterpretations, and convert un-implemented commands and responses
for different levels of feature implementation.  I am all for making it
easier, and if this group can make it easier and more reliable with this
effort, then I am up to learning all about it.  My past experience tells
me this could be difficult.  I will attempt an unbiased watching of this
as it develops.  Good Luck.

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:	Friday, June 22, 2001 10: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