Subject: iSCSI simplification

From: [email-masked]
Date: Fri, 22 Jun 2001 20:06:22 -0400

The word "profiles" is leading to unproductive analogies
to profiles that have been used in other standards contexts.

Many of the cited examples of profiles in other standards
contexts are efforts to clean up interoperability
messes after the fact, leading one of our ADs
to inform us that making the mess in the first place
will not be permitted:

> there seems to be a misunderstanding somewhere - I was trying to say
> nicely that a IPS protocol that has to have profiles would not pass
> the IESG but I guess I was too nice - 

Not only will it not pass the IESG - it's rather unlikely
to get to WG Last Call, as your WG co-chairs have a duty
not to Last Call a document in that state.  In particular,
the Fibre Channel profiles are (unfortunately) examples
of what not to do.

We need to use words other than "profiles" because
people don't agree on what that means, and some of the
ideas it covers are actually useful.  When Julian says:

> have them REPLACE the plethora or features we have now and will
> contain a fixed set of capabilities

this is headed in a useful direction.  Rather than using
the term "profiles", I would talk about subsets of the
protocol and conformance requirements.

Truth be told, I did encourage Mark to post a pointer
to the spreadsheet, not so much to encourage work on
that spreadsheet, but rather, as Mark says:

> [...] it will help show the sheer number of optional features we
> are faced with, and may help us prioritize what must stay in the
> protocol, and what we could live without in the interest of
> simplicity.

I count over 100 optional items in that listing,
a number that has at least one too many zeros.

Matt's comment on Fibre Channel use of profiles is an
opportunity to make an important point:

> Why have two profiles?  Just like in fibre channel, have one profile that
> describes the parameters to be used to be interoperable with other devices
> (would be your profile 0).  The other profile is simply the iSCSI spec,
where
> everything is open and negotiable.

The IETF approach to this is to bit-bucket everything
not involved in interoperability.  The result is that
there isn't a need for a "profile 0" because everything
outside it is either excised from the spec or has words
like "MUST" or "MUST NOT" (cf. RFC 2119) attached to it
to indicate what is required for interoperability.

Thanks,
--David

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

---

From: "Matt Wakeley" <[email-masked]>
Date: Fri, 22 Jun 2001 19:29:26 -0700

I doubt there will ever be agreement on what to "eliminate".... some people
want multiple connections because they think it will improve performance,
others want the simplicity of one... some people want CRCs mandated for data
integrity... others don't because it slows down their software
implementation... some people want markers because it accelerates hw
performance and reduces cost... the software implementations will complain
about that too, then there's the "warp" camp that will complain because
markers eliminate some of their ammunition for getting that.  Some want
precise error recovery, others want the big hammer approach.  And I won't even
get into the discovery stuff....

The "interoperability plugfest" will test to two  versions of the spec (0 vs
0.6) - that's interoperability for you!

-Matt