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

["Williams, Jim" <Jim.Williams@emulex.com>]

> Oh boy, now I'm well and truly frightened.
> 
> I read your message as saying that there isn't going to be
> interoperability for several years.  So rather than create a serious
> incentive for implementers to fix their defects, we should implement a
> way to have them report which collection of defects they implement so
> we can invoke workaround collection #42.  Of course, the larger the
> collection of crocks we work around, the larger the number of bugs in
> implementations that everyone else will have to work around.
> 
> In the words of a well known American, "Just Say NO".
> 
>      paul

I am not sure if I agree with the conclusion or not, but
I have some concerns about the reasoning behind it.

1. If history is a guide regarding standards of this complexity,
then it will likely take some years to resolve all the interoperability
issues.  So what is the best thing to do in the mean time?  Is
it to make the interoperability issues as painful as possible
as an incentive to fix them quickly?  Or is it to make working
around as easy as possible so as to foster development of a
market and create a financial incentive to fix them at all.

2.  I don't think it's valid to assume that interoperability
problems are necessarily due to defects in the implementation.
In fact, those are probably the easier ones to address.  The
harder ones are due to defects in the standard itself.
Suppose vendor A and vendor B don't interoperate, but the
standard is sufficiently ambiguous that both are fully
compliant.  The next rev of the standard needs to fix this,
but what is vendor C to do in the mean time?  Also if the
standard itself has some defects that need to be worked
around by vendors, likely different vendor's work arounds
will not be fully interoperable for some period of time. 

Of course, if the standard is perfect, things are a lot
easier.  But I am reluctant to assume that as a given.