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

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Jim" == Williams, Jim <Jim.Williams@emulex.com> writes:

 >> 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

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

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

Clearly I'm looking for the former.  From Ken's comments, it's already
true that some implementers are taking much too long to fix interop
problems.  Anything that lengthens the MTTR is in my opinion a bad
thing. 

I can think of a large number of complex protocols that have adopted
this hard nosed attitude.  The routing protocols; IPsec/IKE; ATM
PNNI... none of these send vendor IDs and none of them allow this sort
of stuff.

Putting in lots of variable workarounds is a recipe for low quality.
You end up with a lot more code, its specifications are very ill
defined (because by definition it deals with malfunctioning
implementations), and your test matrix just keeps growing and
growing...  Does that make workaround easier?  Maybe, for a few
months.  Does it foster development of a successful market for the
technology?  That's not clear at all.

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

I expect you're right to say that some interop problems will be due to
standards defects.  That makes it all the more important to deal with
those directly and promptly, rather than put in as many workarounds
as there are implementations of the standard.

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

Yes.  If the standard is correct, then conformance implies
interoperability.  Unfortunately, few standards are that good.  And,
even more unfortunately, modern standards processes explicitly
discourage that level of quality in protocol standards.

     paul