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

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

> -----Original Message-----
> From: Brent Callaghan [mailto:[email-masked]] 
> Sent: Wednesday, August 24, 2005 10:47 AM
> To: [email-masked]
> Subject: Re: [nfsv4] draft-eisler-nfsv4-impid-00.txt
> 
> 
> > J.j Bruce Fields writes:
> 
> > Actually, could you get most of what you want just with 
> existing tools
> > for tcp/ip fingerprinting?
> 
> Sure, especially if the implementations helped with a few clues.
> 
> One obvious one is the tag string the accompanies every compound.
> 
> Implementations could easily append some implementation ID bytes
> to the tag string for some infrequently occuring op.  For instance, on
> a PUTROOTFH the client could append its ID, and the server could
> do the same on the reply.  Just a few bytes with a contraction of
> the product name and version - or Mike's nfs_impl_id data.
> 
> This could be done within the existing 4.0 protocol.

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.

But certainly there's enough in NFSv4.0 for clients to 
send impids to servers. I was trying provide a 
method for clients to learn the server impid.

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

---

From: David Robinson <[email-masked]>
Date: Wed, 24 Aug 2005 13:32:29 -0500

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

I would argue that based on this language no client can
depend on the value being equal, so if we have a good
reason to change make it different we can.

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.

	-David