Re: profiles - a way to simplify iSCSI

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

Hmm..this is somewhat tempting.

 The parameters seem to fall into 2-3 clusters
(1)  initialR2T, maxR2T, immediate data, firstburst, pdulength, etc
(2)  the marker related keys
(3)  names, aliases, bootsession, maxconnections, loginlogout min-max.

It would be nice if a "profile" could simplify these dependencies.

Under this proposed setup, I presume the target & initiator would first 
send a profile-name which would initialize the appropriate parameters 
in the set.  If a vendor is unsure of a particular profile, support 
for it would not be advertised.  Once a profile is decided, only 
numeric keys would be negotiated.

Could you elaborate further on your proposal ?

-Sandeep

julian_satran@il.ibm.com wrote:
> 
> 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