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

From: "Williams, Jim" <[email-masked]>
Date: Fri, 7 Jun 2002 13:19:33 -0400

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

---

From: Paul Koning <[email-masked]>
Date: Fri, 7 Jun 2002 15:26:50 -0400

>>>>> "Jim" == Williams, Jim <[email-masked]> writes:

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

 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

---

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

> discourage that level of quality in protocol standards.

Oh my! I absolutely didn't know this.

Worse than that I thought that the exact opposite
would be true.

Well then, this nullifies everything I've posted to IPS.

Just one thing to mention, though:
Writing a ``computer program'' to implement Protocol X
explicitly formalizes Protocol X. Should the industry
adopt a certain company implementation's behaviour,
then Protocol X has been formalized industry-wide,
which I thought was the document's function.

-- 
Luben