Subject: Re: Upcoming draft-07 for NFSv4

From: David Robinson <[email-masked]>
Date: Mon, 10 Apr 2000 15:23:12 -0700 (PDT)

> > If we start imposing rules on what is and what is not a valid
> > COMPOUND op, we may be forcing the server to fully parse the
> > request before evaluating any of it, which might be a burden on
> > implementors.
> > 
> > Instead of requiring a GETFH, why not simply add a file handle
> > to the result of the OPEN?  This will add a very minimal overhead
> 
> Having an op other than GETFH that returns an fh makes the server's COMPOUND
> processing less streamlined. In any case,  at this juncture (last iesg call),
> I think changing the wire formats is too much change for a spec that is in
> last call.  If changing the semantic to an implicit CLOSE is too high a
> burden, then I think adding some warning text to the OPEN Implemention
> subsection is the right amount of change.

Are you implying that by not changing it, defers the change until after
proposed standard but changing it for draft standard or it will
stay this way forever?  If the former I don't like it but will not
raise a stink, although moving to proposed standard will imply
multiple implementations that may have to make incompatible wire changes
after it moves to draft standard which seems worse to me than making
some text changes now.  If the latter I strongly disagree because
it will force all servers to take extrordinary measures to prevent
clients from orphaning locks and potentially denial of service attacks.
Given the complex scenerios that Noveck just described we should fix
what I consider a large hole.

	-David
		"Haste makes waste and a lot of stew"

---

From: Brent Callaghan <[email-masked]>
Date: Mon, 10 Apr 2000 18:03:09 -0700 (PDT)

Mike Eisler writes:
> > don't do that, client should be strongly warned that 
> > they had better do a GETFH after each OPEN (and save
> > the results).  Servers should be warned not to do 
> > anti-social things like returning NFS4ERR_RESOURCE
> > on the GETFH following an OPEN.
> 
> I favor a strong warning to the client and server.

Me too.

I've got an NFSv4 client that ignores much
of the cruft that comes back from OPEN.  It could
just as easily ignore a filehandle too.

The client implementor needs to be warned of the
obligation of state that comes with OPEN.

	Brent