Subject: RE: [nfsv4] (no subject)

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 24 Aug 2005 15:31:51 -0400

Clearly this would not be the only source of information about
what to test.  Another source is people who try a given client
and find it doesn't work.  Then somebody will try to find out
why and if it is our fault, we try to fix it.

The issue that Mike addresses is different.  If you are working
with a particular client and people are using that client for
important applications then when you change your system (for
example to respond to that first client's problem, you want to
make extra sure that you don't break other clients that actually
work that people are using).  The fact that you might further
break a client that doesn't really work anyway that customers
don't use has to be considered secondary.  Testing has to 
focus on clients that people are currently using because such
customers are depending on maintaining existing interoperability
in the face of upgrades.  That's where the information that Mike
is asking for would be most helpful to server vendors, and,
indirectly to their customer's.  I would assume that similar
considerations would apply in the case of testing changed clients
with the set of servers that those customers actually use.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2005 3:12 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] (no subject)

On Wed, Aug 24, 2005 at 11:56:53AM -0700, Mike Eisler wrote:
> > From: David Robinson [mailto:[email-masked]] 
> > That said, I do not think that an impid should be created.
> > We have many years experience with doing interoperability
> > testing and getting implementors to fix broken code. I see
> > no evidence that the existing processes don't work and
> > will require some implementors to work around those that
> > refuse to fix their systems.
> 
> That's not at all why I want impids. I want them so I 
> can determine what my customers are using, so that I can
> know what to focus my QA group's interoperability testing
> on.

If the purpose is not debugging but survey research, then you have to
question the sample design--the implementation you'd most like to focus
testing on might be one that never shows up in the customers' logs,
because they know it doesn't interoperate (even though they might like
it to).

--b.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Aug 2005 15:33:03 -0500

On Wed, Aug 24, 2005 at 03:31:51PM -0400, Noveck, Dave wrote:
> work that people are using).

Er, this sounds exactly like negotiation of bugs by IMPID... :^)

---

From: Mike Eisler <[email-masked]>
Date: Wed, 24 Aug 2005 13:54:31 -0700 (PDT)

> Er, this sounds exactly like negotiation of bugs by IMPID... :^)

Potentially it is forcing the vendor's server product to the least
common denominator. It is more likely that if that the server vendor works
with the client vendors that are broken to get patches ready. Or, or in
addition, documentation can be prepared by the vendor to advise customers
what will happen if the combine client impid X, with server impid Y, using
feature Z, and BTW, here is workound W to deal with it. 

I wouldn't have to look too hard on sun.com (for example :-) for documentation,
white papers, etc. that talk about interoperability issues. I suspect some
of those docs were even jointly written with NetApp. :-)

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Aug 2005 16:01:35 -0500

> of those docs were even jointly written with NetApp. :-)

I agree that there may be a case for this, but if IMPIDs be there then
we have to expect that they will be used for bug/workaround negotiation
before long.