RE: profiles - a way to simplify iSCSI

[julian_satran@il.ibm.com]

David,

I would like to clarify a semantic nit before a go to your more substantive
questions.
I do not mean that we have to introduce profiles (as some other RFCs have)
as accompanying docs but rather make 2 or 3 profiles part of iSCSI and have
them REPLACE the plethora or features we have now and will contain a fixed
set of capabilities (e.g. a device that declares itself profile 0 has only
the features mandatory to implement while a device that declares itself
profile-x has all the mandatory and optional features).

As for why do we have so many things that can be negotiated - I think we
have less than many other standards but we  have to face the fact that
different segments of our community target different parts of the SCSI
solutions domain
and each of the have legitimate concerns about functions and price.

Julo



Black_David@emc.com on 22-06-2001 02:23:28

Please respond to Black_David@emc.com

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




> 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

All worthy questions, but I think one important one
is left out - Why does iSCSI have so many negotiable
parameters/features? This leads into ...

> I assume that many of you are wondering, as I do, if all this flexibility
> is really worth it's price.

If it leads to implementations that fail to
interoperate, the answer is "no".

> 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 think it's incumbent on the WG to reduce the amount
of flexibility by removing things and restricting
implementation flexibility (e.g., specifying that for a
certain set of features implementations MUST support
all of the features in the set if they support any one
of them).  This belongs in the main body of the
specification, not a separate profile.  See RFC 2119
for the appropriate terms to use in specifying requirements
for implementations.

IMHO, if a specification requires profiles in order to
obtain interoperable implementations, then the specification
itself is insufficiently precise and needs to be tightened
in order to merit approval as a proposed standard RFC.

It's time to start thinking about what we can take out ...

Writing as an IPS WG co-chair,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------