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

From: Robert Snively <[email-masked]>
Date: Fri, 7 Jun 2002 13:54:48 -0700

Comments below.

> From: Bill Studenmund [mailto:[email-masked]]
> On Fri, 7 Jun 2002, Robert Snively wrote:
> 
> > The management component already has standard mechanisms
> > for determining such information, including MIBs and CIM
> > objects.  The operational components already have standard
> > mechanisms for determining such information, including
> > SCSI INQUIRY commands.  I cannot see how this additional
> > (non-standard) mechanism for capturing this information is
> > going to help iSCSI achieve its goals.
> 
> 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.

> So I'm confused how an SDS answers a SCSI INQUIRY. I thought 
> that was the
> domain of the device(s) at the other end of the connection, 
> not the domain
> of the connection itself.

---

From: Bill Studenmund <[email-masked]>
Date: Fri, 7 Jun 2002 14:33:27 -0700 (PDT)

> being iSCSI it has already specified its interoperability

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

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 07 Jun 2002 19:18:14 -0400

> compliant *iSCSI* systems. ??

I haven't checked for those lately, (especially in the login procedure),
but any time you see ``MAY'' or ``may'' in the draft and a target
and initiator arrive at different outcomes _just_ by taking one
or the other route, you have ``compliant-non-interoperability''
(as you coined the term).
 
> My technical writing skills aren't up
> $$ off of an intro book.

There are books that talk about iSCSI now.

I bet that just one month after iSCSI becomes a standard,
you'll see 10 books on iSCSI, 5 for Unix/Linux (2 of them
with CDs + implementations) and 5 for Windoze.

I can think of at least one Linux Guru who's known to
write books like that (for a month's time) and who might
be considering this.
 
> way as the other longer-term members, and they don't always see that

This basically is the old conundrum: 
How does one express one's ideas in the most unambiguous way?

We don't know of a better way than formalism (i.e. mathematics).

This is the reason I've been asking to be more formal
in the draft. And I'm not just whining, as I've made it clear
that I can volunteer time.

This is why 4.1 and 1. exist in their current form.
This is also why I've been trying to get the CRC algorithm
in 11.1 become more formal, which would make it more clear
and straightforward to implement. And this is why I'd like
to see someone draw the decision graphs for the login/text
stage/negotiations for the T and I -- then any problems
will be evident. And this is why Robert of UNH started the
variables' dependency charts.
 
> So what do we do?

The rest of us (certainly me) cannot do anything. I can just wait.
(I can only correct spelling mistakes and missed periods,
and such, like this one )

It would be interesing to see the development of iSCSI
and the reaction of the rest of the industry and (closer to my heart)
the Linux community once iSCSI becomes a standard.

-- 
Luben

---

From: Paul Koning <[email-masked]>
Date: Sun, 9 Jun 2002 14:16:09 -0400

> (as you coined the term).

That is not true at all.  "MAY" is fine if either choice results in
behavior that is acceptable to the other side.  In fact, that's the
only place where a standard is allowed to use it.  Sometimes,
achieving that requires that side A communicates its choice to side B;
in other cases it doesn't.

A very simple example is the use of MAY in the rules for responding to
protocol violations.  Since those cases don't occur in the first place
in conforming implementations, neither choice can possible result in
compliant non-interoperability.

If the spec allows a choice -- either with MAY or with MUST -- but the
conforming other end will for one of those two choices -- then the
spec is broken, pure and simple.

	paul

---

From: Luben Tuikov <[email-masked]>
Date: Sun, 09 Jun 2002 19:30:16 -0400

> in other cases it doesn't.

That is not true at all.

Paul, you are NOT reading the whole sentence. Here it is again:

Any time you have ``MAY'' or ``may'' in the draft _AND_
a target and initiator arrive at different outcomes
just by taking one or the other route, there will
be ``compliant'' interoperability problems.

Those two messages show exactly what I have in mind:

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10158.html
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09751.html

This has since been fixed in the draft.

> compliant non-interoperability.

Using this kind of ``proof'' you can easily prove anything...
 
> spec is broken, pure and simple.

Paul, only ``MAY'' allows a choice. ``MUST'' doesn't.
I'd rather ONLY see ``MUST'' and ``SHOULD'' in a spec.

And no, it is not so simple. Finding problems like those
involves drawing a decision graph and enumerating the final
nodes/states and then comparing if you get the same ``number''
for a target and initiator taking different route on MAY.
This is described in the literature.

-- 
Luben

---

From: "Michael J. S. Smith (PacBell)" <[email-masked]>
Date: Sun, 09 Jun 2002 12:23:39 -0700

I'm trying to bound some of the iSCSI structures. This email is regarding
the AHS for extended CDBs.

The following (page 37 of the PDF, page 7 in the draft page numbering) is
from ftp://ftp.t10.org/t10/drafts/spc3/spc3r07.pdf. SPC-3 contains the
third-generation definition of the basic commands for all SCSI devices.
{Date: 2002/05/03, Rev: 07, Status: Development, Project: 1416-D, File:
spc3r07.pdf (2697091 bytes)} (see http://www.t10.org/drafts.htm#CMNDSETS)

[quote]

Command descriptor block (CDB): The structure used to communicate commands
from an application client to a device server. A CDB may have a fixed length
of up to 16 bytes or a variable length of between 12 and 260 bytes.

[end quote]

I can't find another reference within the 442 pages of the 07 draft of SPC-3
to the 260-byte maximum length for a variable-length CDB.

1. Is the 260-byte figure in the definitions section of the 07 draft of
SPC-3 correct?
2. Is it intended that the maximum length of ExtendedCDB field in the iSCSI
Extended CDB AHS comes from SPC-3?

I searched the mail archive and I did find a discussion between Julo and Bob
on the AHS format, but can't find a definitive answer to the last question.

Aloha

Mike Smith
CTO, iReady

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 10 Jun 2002 09:44:28 -0700 (PDT)

> (as you coined the term).

I must say that's not what I had in mind when I coined the phrase. I don't
think the fact we let folks make different choices at MAY points is bad.
That's the point.

I thought most of them were of the form, you MAY close the connection, or
you MAY do some error cleanup & try to recover. So both sides know
something happened.

What I'd be worried about are places where different sides both thing
things are ok, but get on entirely different pages as to what exactly is
going on.

*Those* are what I was thinking of when I came up with compliant-non-
interoperability. :-)

Take care,

Bill

---

From: Luben Tuikov <[email-masked]>
Date: Mon, 10 Jun 2002 14:24:18 -0400

> think the fact we let folks make different choices at MAY points is bad.

You (as Paul) didn't read this sentence (quoted here from above):

Any time you see ``MAY'' or ``may'' in the draft and a target
and initiator arrive at different outcomes _just_ by taking one
or the other route, you have ``compliant-non-interoperability''.

Which is what you are describing in more ``baby-terms'' below.

Read my reply to Paul, where I give 2 links to emails
where this is described well -- this has since been fixed
in the draft.

BTW, I don't like ``MAY'' and ``may'' -- I don't use those
two words personally and I sure don't like them in the spec as well.
 
> *Those* are what I was thinking of when I came up with compliant-non-

But you are merely repeating what I'm saying above... (and in my previous
email).

-- 
Luben

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 10 Jun 2002 11:51:05 -0700 (PDT)

> You (as Paul) didn't read this sentence (quoted here from above):

Yes, I did.

> Which is what you are describing in more ``baby-terms'' below.

No, that's not the same thing. You are saying EVERY may/MAY is a problem.
I disagree with that. I'll agree that SOME may be a problem, and that we
want to find them.

The difference is that the ones I recall describe one side as being able
to make a choice. If that choice is clearly communicated to the other
side, then we are fine. I think we communicate that all of the time, but
would appreciate finding out if we don't.

> where this is described well -- this has since been fixed

Cool!

> But you are merely repeating what I'm saying above... (and in my previous

No, the difference is I don't think that a MAY automatically lands us in
trouble. I agree that most trouble cases start with a MAY, but I don't
think the presence of a MAY automatically leads us to trouble.

Take care,

Bill

---

From: Luben Tuikov <[email-masked]>
Date: Mon, 10 Jun 2002 16:30:10 -0400

> I disagree with that. I'll agree that SOME may be a problem, and that we

``Any time'' doesn't imply ``EVERY may/MAY''!

Look, I used the conjunctive ``and''.

Here:

   (Every time ... MAY or may)
AND
   (target/initiator arrive at different outcomes)
THEN
   problem.

-- 
Luben

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 10 Jun 2002 11:51:05 -0700 (PDT)

Yes, I did.

Cool!

Take care,

Bill

---

From: Luben Tuikov <[email-masked]>
Date: Mon, 10 Jun 2002 16:30:10 -0400

Here:

-- 
Luben

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 10 Jun 2002 11:51:05 -0700 (PDT)

Yes, I did.

Cool!

Take care,

Bill

---

From: Luben Tuikov <[email-masked]>
Date: Mon, 10 Jun 2002 16:30:10 -0400

Here:

-- 
Luben