RE: profiles - a way to simplify iSCSI

[julian_satran@il.ibm.com]

Bernard,

I understand you well stated (and well intentioned remarks) and it is hard
not too agree with motherhood statements.
However I have to mention that most of the features where added with care
and only a very few remained after selection. Peace was not what we had in
mind - but you can't outright reject feature that have a clearer rationale
for a class of users.

However the draft addresses a wide spectrum of devices with different
requirements (as do most of the SCSI drafts). Some can be met only with
minimal requirement (most low-end and office raid-boxes) while others
require higher performance/reliability/maintainability etc.

Profiles could clearly cluster the space and simplify implementation and
testing.

Regards,
Julo

Bernard Aboba <aboba@internaut.com> on 25-06-2001 09:09:34

Please respond to Bernard Aboba <aboba@internaut.com>

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




> 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.
>

The best way to limit the variability in implementations and testing is
not to include so many "features" in the first place. It's often tempting
to resolve potential conflicts by turning out a "kitchen sink spec" but
that's almost always a worse choice than choosing between one of the
alternatives. Similarly, options are a losing proposition because you have
to implement them because someone else might, but you can't guarantee
they'll be used. So if something doesn't make it into what would have been
the "profile" I'd question why it can't be thrown out altogether.

As part of the Draft Standards application, "features" not proven to
interoperate with independent implementations have to be removed. So if a
"feature" was inserted merely to keep the peace, has problematic
interoperability or is not on the slate to be independently implemented,
we might as well toss it out.

"There's never a better time to weed a garden than RIGHT NOW."