Subject: [nfsv4] draft-eisler-nfsv4-impid-00.txt

From: Mike Eisler <[email-masked]>
Date: Tue, 23 Aug 2005 17:51:41 -0700 (PDT)

I thought people might be interested in this personal I-D:

> 	Title		: Identifying Implementations in NFSv4
> 	Author(s)	: M. Eisler
> 	Filename	: draft-eisler-nfsv4-impid-00.txt
> 	Pages		: 
> 	Date		: 2005-9-22
> 	
>    NFSv4.0 has no method for allowing clients and servers to provide to
>    each other their implementation identities. An implementation
>    identity might contain the name of the software that embodies the
>    NFSv4 client or server, and the version number of the software. This
>    proposal describes how a future minor version of NFSv4.0 could allow
>    clients and servers to exchange implementation identities.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-eisler-nfsv4-impid-00.txt

I have received one comment on this:

> I suppose this will allow clients and servers to code in workarounds
> for known bugs in particular implementations.  Essentially a way
> to version a minor version. :-)

I see the above as a potential weakness in the proposal, 
and not a strength. The proposal explicitly bans such behavior, 
and also mandates that servers and clients be configurable to 
prevent the sending of implementation info, and be configurable to 
forge implementation info (since the temptation to break the rule 
will always be there). Not just because I'm against custom NFSv4 versions 
(Balkanization), but because I'm against clients and servers that 
refuse to talk to each other (the way web sites refuse
to talk to all browsers, such as my browser).

The intent of the proposal is to give providers of NFS clients 
and servers insight into what NFS implementations customers are 
connecting to their products in order to better serve the customer. 
For example, I can tell you in details like collectively how many 
NFSv2 GETATTRs my employer's customers sent to "our" NFS servers last month,
but I can't tell you how many were BSD, Linux, Solaris, HP/UX, AIX, etc, much
less what release versions of each . So I can't give  my QA group
a scientific basis for where to invest in its interoperability 
testing, short of darkening the machine room with every possible 
client out there. My hope is that the benefits out weight the risk 
of abuse of this feature.

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 23 Aug 2005 21:33:24 -0400

> to talk to all browsers, such as my browser).

Yup.  This always seems to cause trouble.

Besides the well-known http/html morass of mutually
compensating/cancelling hacks,
the presence of this info in ssh v2 has led to mysterious interop
problems -- the presence of a hardcoded quirk table in one
implementation permitted interop with another implementation, until you
changed that 2nd implementation's name....

						- Bill

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Aug 2005 10:07:13 -0500

> changed that 2nd implementation's name....

Hear, hear!  IMPIDs, software versions, cause trouble.

This kind of problem could be "avoided," if we *really* want IMPIDs, by
first admitting that it IMPIDs will almost certainly be used as indexes
to bug/workaround databases and then requiring that such databases be
configurable (at least on servers).

Nico
--

---

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

On Tue, Aug 23, 2005 at 05:51:41PM -0700, Mike Eisler wrote:
> less what release versions of each.

Have you looked into how far you could get with just passive
fingerprinting?  It might not be that hard.

I bet you could distinguish any existing implementations just by
examining the first couple compounds they send.  Heck, there may be
people that have been coming to bakeathons for a while that can do that
on sight already....

Actually, could you get most of what you want just with existing tools
for tcp/ip fingerprinting?

--b.

---

From: Brent Welch <[email-masked]>
Date: Wed, 24 Aug 2005 10:33:14 -0700

I prefer an explicit IMPID, beyond fingerprinting.
I think anyone that burns IMPID-compensating code into their
implementation is asking for trouble.  I'd be content with
stating in the ID that such behavior is "banned", and explain
why it is a losing battle to try to compensate for bugs this way.
The goal is to correlate problems with implementations so the
implementations can be fixed, not to compensate.

>>>"J. Bruce Fields" said:
 > > NFSv2 GETATTRs my employer's customers sent to "our" NFS servers last 
mont
     h,
 > > but I can't tell you how many were BSD, Linux, Solaris, HP/UX, AIX, 
etc, m
     uch

--
Brent Welch
Software Architect, Panasas Inc
Accelerating Time to Results(tm) with Clustered Storage

www.panasas.com
[email-masked]

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 24 Aug 2005 13:41:05 -0400

> I prefer an explicit IMPID, beyond fingerprinting.

Why?

> implementations can be fixed, not to compensate.

Yeah.  But a proper solution can be complicated and time consuming and
require work from other implementors.  Given a simple patch that does an
IMPID-based workaround, and pressure from customers to solve a problem
*now*, I imagine the temptation could be rather strong....

--b.

---

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

I think this is going to be as fun as getting a minor version field into
COMPOUND was. :-)

> > Yup.  This always seems to cause trouble.

While they cause problems for Firefox, they don't seem to for
Opera, because Opera lets the user override the impid in the
event the user's access to a web page is denied.

In the proposal you'll note that the impid exchange is
done only if the client wants to
as opposed to http and apparently ssh,
where the impid exchange is mandatory. I don't see that it is practical for
NFSv4 servers to change or deny behavior based on client impid, because
the impid exchange can happen at anytime after the clientid is set.

Whereas, as proposed, it would be easy for clients to change or deny
behavior based on server impid. If that's a major concern, we can drop
server impids from the proposal, or change the proposal so that servers
can receive client impids but deny sending the client the server impid.
I was trying to be fair to client vendors. The alternative of using 
GETATTR and SETATTR is discussed in the proposal. It would be a simple
matter of dropping the GETATTR for the new recv_impl_id, and leaving 
the SETATTR for the send_impl_id attribute in pace.

---

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

> > I prefer an explicit IMPID, beyond fingerprinting.

It is going to be hard for a finger print going to distinguish say
Linux 2.x.y-z from 2.x.y-v. Finger prints also can't distinguish machine
architectures. What if -v is changes to something which changes the fingerprint,
for e.g. the Linux client might someday send non-zero-length tags. :-)

> Yeah.  But a proper solution can be complicated and time consuming and

That's the situation we have today.

> *now*, I imagine the temptation could be rather strong....

Thus far NetApp has resisted treating clients with zero length tags differnently
from those with those with meaningful tags.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Aug 2005 13:32:06 -0500

> I think this is going to be as fun as getting a minor version field into

Negotiating features[/bugs :^)] seems better, to me, than negotiating
IMPIDs to negotiate features/bugs (for which, though IMPIDs might not be
intended, IMPIDs will be used).

That's Robert's proposal: a la carte minor version negotiation.  I
wholeheartedly support it.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 24 Aug 2005 12:59:36 -0700

> > http://www.ietf.org/internet-drafts/draft-eisler-nfsv4-impid-00.txt

Mike,

 Given that we're basically replacing SETCLIENTID in 4.1 with the
sessions stuff, why could we not do this by adding a "nfs_impl_id" field
to the new CREATECLIENTID operation, and having the server reply with
its id?

Cheers,
  Trond

---

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

> to the new CREATECLIENTID operation, and having the server reply with

Trond,

Yes we could. However, that increases the danger of
servers rejecting or massaging behavior based on impid. It starts
to look like what happens when I try to use firefox to file an
expense report, and it isn't pretty.

As a separate operation or pair of attributes, the impid exchange is
decoupled from the session or client id set up. it is also something
the client chooses to participate in rather than having the server
force it. That appeals to concerns anyone (including) me, might
have about personal privacy.

In addition, there has been push back on other new features being
tied to sessions, such as directory delegations.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 24 Aug 2005 15:23:56 -0700

> expense report, and it isn't pretty.

I fully agree that is undesirable, but that is the particular Pandora's
box you are proposing to open. The ability for clients or servers to
massage behaviour based on impid does not depend on the particular
operation you use to implement it.

If that is the major worry, then perhaps we should just settle for
mapping clientids/ip-addresses to impid information via some other
protocol that doesn't involve the NFS client/server (snmp springs to
mind).

> have about personal privacy.

It can be designed in such a way as to be optional in CREATECLIENTID
too: that's just a question of adding a flag.
The point is that it doesn't really make sense to perform this operation
more than once or at any time other than at boot time.

> tied to sessions, such as directory delegations.

Fair enough.

Cheers,
  Trond

---

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

> box you are proposing to open. The ability for clients or servers to

I proposing to make the box open slightly so that the vermin can't
escape. Hence, leaving the impid eachange as a separate and optional step for
the client.

Whereas, with http, it is unavoidable; the http client has to present
his impid in order to get service.

> protocol that doesn't involve the NFS client/server (snmp springs to

Yikes. Sideband protocols. In any case, this requires customers to send
phone home info for both clients and servers to both the client and server vendors.
I can imagine there will be political issues with each vendor having access to
the others phone home traffic.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 24 Aug 2005 17:03:13 -0700

> escape. Hence, leaving the impid eachange as a separate and optional step for

How does that change anything? A vendor could still use this to tune
performance when enabled. I'm sure that a suitably helpful salesperson
would be quite happy to pass on the information that "you can get an
extra n% performance out of your system by enabling this option".

> Yikes. Sideband protocols.

Yes? This is for optional behaviour that is hardly application-critical.

> In any case, this requires customers to send

I'm not following you. Why does doing the mapping out of band change
anything w.r.t. what information the customer sends back to a vendor?

Cheers,
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Wed, 24 Aug 2005 19:28:07 -0700 (PDT)

--- TronTrondlMyklebustontrondlmyklebust.fys.uio wrote:

> on den 24.08.2005 KlokKlokka00 (-0700) skreskreive EislEisler > I proposing to make the box open
slightly so that the vermin can't
> > escape. Hence, leaving the impiimpidheachangea separate and optional step for
> > the client.
> 

What's an example of where that be possible? Why would an NFS NFSdor cripple
his product and use an option to be enabled on the *peer* to speed
it up. It would be more likely the vendor would cripple his product
and use a licensed option on his product to enable performance.

> > > mapping clieclientidsaipresses to impiimpidormation via some other
> > > protocol that doesn't involve the NFS NFSent/server (snmpsnmpings to
> > > mind).
> > 
> Yes? This is for optional behabehaviourt is hardly application-critical.

A sideband protocol runs the risk of not getting implemented, or not getting
through, and is more moving parts for the system administrator to
deal with.

> anything w.r.t. what information the customer sends back to a vendor?

You said snmpsnmpwas thinking the snmpsnmpff would be sent directly sent to
the automatic support center. It sounds like you are thinking that
an NFS NFSver would issue snmpsnmpuests back to the client. If so there are
two issues. One we are back to requiring separate callback path that NFSvNFSvessions is supposed
to solve. Two, whether the server gets the information
via NFSvNFSvor whether he gets it via snmpsnmpes no difference. He can still use
the impiimpidmodify the behavior of the server or refuse service.