Re: profiles - a way to simplify iSCSI

["John Hufferd" <hufferd@us.ibm.com>]

I have been traveling so I did not put my 2 cents in before now.
First it is not yet understood what is actually needed and what is not
important until things actually get built.  At that time the industry will
begin to consolidate around  the really valuable "Optional to implement".
Like was mentioned on this thread, it is the really  vocal minority that
will yell until an option is included, and the silent majority will go
about building what makes since for their customers.  Further, the silent
majority will remain just that, silent and are not much help when we try to
cut back on options.

An example of this is all the people that complained about the SW
implementations that had to add extra code and path length to support the
Markers.  Now the important thing is that, all the real SW implementations
that are currently being done are being given away for Free by the various
Storage and Routers vendors, or as part of a free option from an OS.  I
know of no one that plans on selling an iSCSI SW iSCSI implementation.
Therefore, in the real world, the folks that were complaining, were not
going to implement a SW iSCSI version, anyway.  They were just debating for
effect.  And this has been causing some disarray in the HW iSCSI HBAs (Host
Buss Adapters) arena.  There is probably no way to stop this, and if we
attempt to do that, by defining profiles, in the IETF, it will just cause
the debates to start all over again.  Many of us, I am sure, were glad to
have moved on to other topics when a contentious item was made an option,
since we knew we were not going to implement it, and doubted if in the real
world anyone would.  Some of us felt that either the option would not be
implemented by two or more vendors, or if it was, the market place would
make it go away.  The IETF process will address the issue of less then two
implementations, and one of the purposes of the SNIA IP Storage Forum and
Technical Workgroup is to help define the marketing needs and the profiles
that meet these needs.

Now let me explain about the marketing needs and their related profiles.
As an example there maybe an important market that addresses, iSCSI needs
within a Business Secure Campus.  There maybe lots of vendors that have
products that fit that market, but several vendors may have decided to have
a low price point, and not include optional items that would be especially
valuable in the Wide Area Market, but not needed in a Business Secure
Campus (e.g. extra RAM).  This set of vendors might feel that they could
meet their revenue goals by focusing only on Business Secure Campuses.
Therefore, they might want to define a set of profiles that would permit
them to meet their targeted market.

I do think we need to clearly define the "Must implement" and that these
must be the Minimum Profile.  However, it is not clear to me that we need
to have profiles defined by the IETF.  If profiles are needed anywhere they
should be produced as part of the SNIA IP Storage (iSCSI) Technical
WorkGroup's response to what the SNIA IP Storage Forum Defines to be a
targeted marketing need.  (Those, profiles can then be used in conformance
test at UNH.)  I do not think that profiles should be part of the IETF
work.

I agree that we should not have more options than will be actually built,
however, the IETF process probably limits this to a great extent.  Also, I
would hate to see us get into the rancorous debates that will follow when
we try to limit options, I do not think we added them wily nilly and that
each one, at the time, seemed to be of value to some set of vocal people.
So I suggest that we be very careful when we try to trim the Options, and
then only those that we know do not make since to any potential profile.


.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com