Subject: profiles - a way to simplify iSCSI

From: [email-masked]
Date: Thu, 21 Jun 2001 20:14:39 +0300

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

---

From: Sandeep Joshi <[email-masked]>
Date: Thu, 21 Jun 2001 14:19:21 -0400

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

---

From: Santosh Rao <[email-masked]>
Date: Thu, 21 Jun 2001 10:53:18 -0700

Julian,

I am in favor of developing an iSCSI profile document along the lines of
FC-PLDA and FC-FLA. This will go a long way in ensuring smoother
interoperability. I had suggested over 4 months ago, that such a profile
of features is useful for iSCSI and should be specified. (ex :
http://ips.pdl.cs.cmu.edu/mail/msg03276.html).

I'm not certain on what one gains by having 2 profiles. Basically, a
profile should only state the requirement for each feature as one of :
R - required
P - Prohibited
A - Allowed
I - Invokable

The mandatory (R) features of the profile constitute the minimal
protocol conformance required. Implementation of the Allowed/Invokable
(A, I) features constitues maximal conformance to the protocol.

There should not be a need for 2 profile documents (?). 

Regards,
Santosh

---

From: "Mark Bradley" <[email-masked]>
Date: Thu, 21 Jun 2001 12:54:59 -0600

This is a very slipery slope.  'Required to be implemented' means that
you must support to be compliant to a specification.  'Flavors' of
implementation to anything other than required sounds like a marketing
playground more than a means of ensuring interoperability.
  --  markb

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Thursday, June 21, 2001 11:15 AM
> To: [email-masked]
> Subject: profiles - a way to simplify iSCSI
>
>
>
>
> Dear colleagues,
>

---

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 21 Jun 2001 11:59:09 -0700

I think this is indicative of the complexity we have in
the standard. The first order of preference should be
to reduce the complexity.

Secondly, given the confusing decision process in the
IETF, it is not certain whether we would meet the following
two goals that I would have

1. Speedy process.
2. A large community of vendors and customers agreeing on
an ideal profile that would be implemented widely.
(of course, that means that everything else in the spec
would be relegated to the position where 5 yrs from now
only few will be able to explain why it is in the spec)

Otherwise profiles are just going to add another dimension
to negotiate without providing much benefit. Unless you
say that profiles completely eliminate parameter negotiation
(then it does add a lot of value).

Somesh

> Sent: Thursday, June 21, 2001 10:15 AM
> To: [email-masked]

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 21 Jun 2001 21:04:04 -0400

> to reduce the complexity.

I agree with Somesh.

When we talked to (some of) the FCP gurus when starting SST, their
single most prominent piece of advice was to avoid options and avoid
profiles.  Seems like motherhood to me.  Profiles usually end up being
ways of pruning features that a vocal minority thought were critical,
and a silent majority didn't really care about and didn't plan to
implement.  It really makes it hard to figure out what you have to
implement, and that's really what happened with FCP.  Then again,
maybe such surprises are in somebody's interest (heck if I can figure
out whom).

Personally, I think we're much better of starting out with a
rock-solid, interoperable first step, and extending from there, than
starting with a specification that covers many anticipated
possibilities that we may get around to eventually.  The IP protocol
suite was developed along those lines (start with something basic, and
then tweak and enhance), and it's worked out well.  SCSI itself
followed that model (ah those grand days before queuing, and single
drop links).  OSI followed the architect everything before we
understand approach and, well at least 2 of those layers fell unused,
not to mention the protocols themselves.

Nonetheless, if y'all really think the spec has to option laden, it
has to be option laden, and NO profiles.  If we make this mess, we
should lie in it.

Steph