RE: iSCSI: Some proposed vendor-specific (X-) keys

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Fri, 7 Jun 2002, Robert Snively wrote:

> > Question about the operational components being able to determine this
> > info. iSCSI is, in terms from SAM-2, a Service Delivery
> > Subsystem (SDS).
> > While many implementations act as scsi servers (disks & tapes, etc.),
> > that's not part of the spec.
> >
>
> You are clearly correct.  By operational components, I
> mean those that are performing SCSI operations.  The
> service delivery system (iSCSI) is already neatly standardized
> and has no need to identify vendor and model, since by
> being iSCSI it has already specified its interoperability
> requirement.

That comment reflects a very nice ideal. My concern is that I'm not sure
we're there. What about Luben's comments that there are existing
interoperability problems among compliant systems? AS I understand him,
compliant *iSCSI* systems. ??

Also, I think there is one general problem with the spec, that I have no
idea how to fix. When I was first reading the spec, it came across as a
document that makes perfect sense once I understand it, but it's rough
getting that initial understanding. My technical writing skills aren't up
to the task to do anything different, and I expect someone will make some
$$ off of an intro book. So I accept it as it is, or make minor
suggestions.

But the problem (as a number of recent threads have shown :-) is that
people who are looking at the spec for the first time don't necessarily
come to understand the spec the same way that the longer-term WG members
do. The longer-term members see the written spec as a clear reflection of
their idea of the spec, so they don't see the problems. They've been to
plug-fests, and so they have a lot of commonality in their mental ideas of
what the spec is. When a choice comes up, they naturally choose the same
way as the other longer-term members, and they don't always see that
they've made a choice.

Now that's not meant as a criticism of the WG or of Julian. As issues have
come up, Julian and the group have worked on clarifying issues. The
problem is that a question has to come up before the clarification
happens. Once we get past last-call, this process will stop until the next
version.

So what do we do? Do we really expect we will stop finding problems after
last-call? If not, do we work with what we have, or not? Adding
vendor/product/revision tags is one way to help implementations deal with
what we have until the next version of the spec can fix problems.

Take care,

Bill