Subject: RE: [nfsv4] (no subject)

From: "wurzl, mario" <[email-masked]>
Date: Wed, 24 Aug 2005 16:10:35 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of J. Bruce Fields
> Sent: Wednesday, August 24, 2005 15:54
> To: Mike Eisler
> Cc: [email-masked]
> Subject: Re: [nfsv4] (no subject)
> 
> On Wed, Aug 24, 2005 at 12:34:37PM -0700, Mike Eisler wrote:
> > It isn't practical to test 10,000 clients. If the top 10 
> client's by 
> > impid represent 50% of the client base, then that is more 
> practical to 
> > test those 10, and the vendor can even document what has 
> been tested.
> 
> How will you use the implementation id to determine the 
> percentage of clients that use a certain implementation?

MW>  The server can keep a count of the impids of the clients that connected
to it.

> It's more likely to tell you something less useful: e.g., the 
> percentage of ip addresses that presented a given 
> implementation id, on servers that you could get this 
> information from.  The potential for strange sorts of sample 
> bias seems rather high.
> 
> --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: "wurzl, mario" <[email-masked]>
Date: Wed, 24 Aug 2005 17:06:53 -0400

> On Behalf Of Nicolas Williams
> Sent: Wednesday, August 24, 2005 17:02
> To: Mike Eisler
> Cc: [email-masked]
> On Wed, Aug 24, 2005 at 01:54:31PM -0700, Mike Eisler wrote:
> > --- Nicolas Williams <[email-masked]> wrote:
> > > 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. :-)
> 
> 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.
Windows has the notion of impid, and I don't see it being used for bug
negotiation.
But, it does help server vendors to decide where to allocate
interoperability test resources,
And also helps in problem reproduction.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 24 Aug 2005 16:12:30 -0700 (PDT)

-----Original Message-----
> From: wurzl, mario [mailto:[email-masked]] 

> > >     The server and client MUST NOT, UNDER ANY CIRCUMSTANCES 
> > WHATSOEVER,
> > >     behave differently as a result of the reciept of a 
> > particular impid
> > >     or the absence of an impid.

> I see cases where it would be useful for a server to change 
> behavior. One
> example is when an interoperability problem occurs in an 
> installation with a
> large number of clients. Even though the problem may be on the client
> implementation, the customer may still choose to ask the 
> server provider to
> come with a workaround, since in a short time-frame it is 
> simpler to patch
> one or a few file-servers, instead of a couple thousand clients.
> Having a server adjust to that particular version of the 
> client, provides
> the customer the ability to  gradually upgrade the clients

I see that it would be useful, but I also see that there are other
ways to provide the workaround without violating the MUST.
E.g. as a workaround stick in a knob to reduce behavior to
a lowest common denominator. 

One problem I see with your example is that with a large number of
clients some of them may get upgraded to implementations that introduce
other problems. So then the customer requests more impid-specific behavior.
And then one of the clients gets allocated for a critical app that may or
may not need the impid-specific behavior. So you might be stuck for a long
time supporting that version-let of NFSv4.