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

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 7 June 2002) by Bill Studenmund:
> ...
> What about the case(s) Luben describes, where due to problems in the spec,
> two different implementations that both follow the spec don't
> interoperate? The case of compliant-non-interoperability?

Those are defects in the spec; if those cases are real then the spec
must be fixed prior to being released.  
 
> I gather that you believe that if we add these keys, we will be opening
> the door to an interoperability mess. I believe that is not correct; we
> either have a spec that permits compliant-non-interoperability, or we
> don't. I do not believe that adding or not adding these keys will change
> that.

That's not what I said.  What I said is that adding these keys will
weaken the incentive to fix the interoperability problems, which will
harm the success of iSCSI.
 
> Also, what do we do with installed systems? Say we find and correct a
> problem. Until our end users upgrade field-deployed systems, the problem
> continues. Are the sysadmins of our customers going to be happy if we try
> to force them to upgrade production "seems-to-work" systems, just because
> we found a bug in the spec? My experience as a sysadmin and with sysadmins
> is that they will say rude things to us and ignore us. That's not a good
> way to sell iSCSI systems. :-|

So what makes iSCSI different from the dozens of protocols that have
been created in the past that do not do this? 
 
> Some people are concerned that adding these keys will permit or tacitly
> encourage us to slide into a mode where we paper over interop problems
> rather than fix them. I think implicit in this point of view is that we
> don't have major interop problems now.

I never said that we do not have major interop problems.  Maybe we do,
maybe we don't.  If we do, how about exposing them explicitly and
FIXING THEM?

> Others (including myself) believe that the WG and the iSCSI vendors will
> do the right thing and not lazily slide into that mess.

I have seen protocols that implement this sort of feature, and based
on that experience I am not as optimistic as you are. 

> So we have a proposal with 4 options and two motivations:
> 
> Proposal for keys:
> 
> 1) Do nothing; don't encourage common-use keys
> 2) Add X-vendor, X-product, and X-revision to the common venacular. They
> 	would of course be "vendor specific," just a number of vendors
> 	would use them.
> 3) Some short-named vendor come forward and add names in its space that
> 	everyone use. Like say X-edu.unh.vendor, X-edu.unh.product...
> 4) Make them standard keys, like Vendor, Product, Revision. I'd vote they
> 	are delcarative and per-direction. And if you talk to something
> 	that doesn't understand them, you'll be talking to vendor
> 	"NotUnderstood". :-)

I am in favor of 1, and object strongly to 2, 3, and 4.

    paul