Subject: [nfsv4] (no subject)

From: Mike Eisler <[email-masked]>
Date: Wed, 24 Aug 2005 11:56:53 -0700 (PDT)

> -----Original Message-----
> From: David Robinson [mailto:[email-masked]] 
> Sent: Wednesday, August 24, 2005 11:32 AM
> To: [email-masked]
> Subject: Re: [nfsv4] draft-eisler-nfsv4-impid-00.txt
> 
> 
> Mike Eisler wrote:
> 
> > That was my one of the ideas I kicked around ... a best 
> practices guide
> > that recommended exactly that. Trouble is, nfsv4.0 mandates
> > that the tag in the reply be equal to that of the response. Then I
> > considered a best practice for a quasi named attributes, but that
> > requires name attribute support which is not mandatory.
> 
> Not required:
> "the value of "tag" in the response SHOULD
> be the same value as provided in the request"

Some servers will adhere to the SHOULD nonetheless.
And so clients logging this imformation for data gathering
and customer support purposes will recording inadverntaly false
data: all the NFS servers at a particular site are running
the same implementation as that running on the client. 

> 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. Using impids to work around NFS implementation defects just
reduces quality as Brent W pointed out.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 24 Aug 2005 15:12:07 -0400

On Wed, Aug 24, 2005 at 11:56:53AM -0700, Mike Eisler wrote:
> 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.

---

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

> If the purpose is not debugging but survey research, then you have to

Debugging is part of it to the extent that getting accurate information
via a verbal phone call from a customer can be challenging. This is
why computer and software makers have constructed "phone home" systems that
send such data to the makers' home offices. So that when a problem happens,
the maker already has most of the information, and the problem can be
resolved sooner (and not by kludges that have giant switch statements on impids).

> because they know it doesn't interoperate (even though they might like

Existing customers will inform a vendor when something doesn't
interoperate; sometimes they'll do it politely. Or prospects 
ask the account rep if it interoperates,
and the account rep will ask engineering. So that sampling is 
taken care of. 

I don't think you are considering all situations. For example,
a server vendor, might add a feature which might directly affect NFS (perhaps
an export option). The question then is, what clients break if the option
is turned on? There are thousands of different NFSv3 implementations
out there now when you consider code base, release, machine architecture. We
can assume that the same will be true of NFSv4 in the future (or the past
9 years have been a waste of our time). 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.

A positive example might be whether the vendor should implement a new 
AES-256-SHA-512 (I don't believe there is one today, but given the
FUD around SHA-* these days perhaps there should be one) encryption
type for Kerberos V5. Knowing how many clients have 
AES-256-SHA-512 support in the customer base helps the vendor make an
informed decision about the investment.

impids are all about serving the users of the "running code" 
we are supposed to be providing. There's no hidden agenda on my 
part for creating vendor specific minor versioning, though Nico alleges 
Robert (G?) has a not so hidden one. :-)

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 24 Aug 2005 15:54:12 -0400

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?

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.

---

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

> clients that use a certain implementation?

The proposal specifies the use of the clientid as returned by SETCLIENTID.
The client id can be used by the server implementsation to index into the
long hand client id, and from there can a more accurate histogram of
impids.

> sorts of sample bias seems rather high.

Are you saying that a vendor might have
lots of customers who chose not to participate in phone home?
We could get into deep discussions as to whether the customers who
do participate are self-selecting toward certain clients or not and create
bias. Even if that is true, it isn't a bad thing if the customers who
opt for the best possible vendor support also get best possible quality
assurance.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 24 Aug 2005 16:36:43 -0400

On Wed, Aug 24, 2005 at 01:23:18PM -0700, Mike Eisler wrote:
> Are you saying that a vendor might have lots of customers who chose
> not to participate in phone home?

Yes, or they participate but the system's broken, etc.  You could also
ask whether clientid (or ip address, or whatever you really want to use)
counts the right thing.  And I'd think you'd want to know which clients
actually matter.  (If a customer has 200 desktops and 1 critical
server, the fact that that the one server represents 0.5% of the NFS
clients may not be a useful statistic.)

> We could get into deep discussions as to whether the customers who do
> participate are self-selecting toward certain clients or not and
> create bias. Even if that is true, it isn't a bad thing if the
> customers who opt for the best possible vendor support also get best
> possible quality assurance.

If you really wanted accurate results I'd think you'd want to have
someone actually do the hard work required to choose a representative
sample of users and study them carefully, rather than just collecting a
lot of superficial data on every user out there.

So I'd think the important question would be whether implementation id's
would be useful to a person doing such a study.

--b.

---

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

> would be useful to a person doing such a study.

They seem to be useful to whoever reports on web server and web browser penetration
by impid. And useful to the ISVs writing plugins and other apps.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 24 Aug 2005 17:23:14 -0400

On Wed, Aug 24, 2005 at 02:12:55PM -0700, Mike Eisler wrote:
> They seem to be useful to whoever reports on web server and web
> browser penetration by impid.

Unfortunately I've only seen those numbers used to generate slashdot
headlines.  But that may be more a reflection on my poor reading habits
than on the statistics themselves.  Do you know of any examples of
someone drawing accurate and useful conclusions from them?

> And useful to the ISVs writing plugins and other apps.

I'm losing the analogy to NFSv4 here.

--b.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 24 Aug 2005 14:35:45 -0700 (PDT)

> someone drawing accurate and useful conclusions from them?

I'm assuming hte peolel who pay for these reports think it is useful, and
make useful decisions on the reports, or they wouldn't keep paying.
 
> I'm losing the analogy to NFSv4 here.

If an ISV uses Netcraft, OneState, WebSideStory, etc.
or similar data to justify an investment in
apps for Apache or Firefox, why wouldn't an NFSv4 vendor use the impids
he's gathered to make investment decisions in features and testing such
as how Mario and I have previously described?