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

[pat_thaler@agilent.com]

Luben,

An IETF standard is suppose to produce interoperability. Therefore, when
there is a MAY in the standard, it should be because each side can choose
either option and they will interoperate independent of which they choose.
For example:

"iSCSI targets and initiators MUST support at least one TCP connection
and MAY support several connections in a session."
A device that supports only one connection per session will interoperate
(over one connection) to a device that supports multiple connections.

Pat

-----Original Message-----
From: Luben Tuikov [mailto:luben@splentec.com]
Sent: Friday, June 07, 2002 4:18 PM
To: Bill Studenmund
Cc: Robert Snively; 'Ken Sandars'; Ips Reflector (E-mail)
Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys


Bill Studenmund wrote:
> 
> 
> 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. ??

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
> to the task to do anything different, and I expect someone will make some
> $$ 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.
 
> 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.

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