Subject: Re: [nfsv4] SSV

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 6 Jan 2010 13:25:14 -0500

On Mon, Dec 21, 2009 at 01:50:13PM -0800, Mike Eisler wrote:
> I don't see what role the error status value has in whether you add
> SSV later.

If there were a clear "SSV_NOT_SUPP" error, then it would be easier to
implement client-side SSV in the presence of servers that may or may not
support it.

In the absence of such an error, if we release servers without SSV
support, then we make it difficult for clients to later add SSV support:
they will be stuck trying to guess what the server means when it replies
SERVERFAULT to an EXCHANGE_ID.

That's all I meant.  Am I making sense?

(The goal here being just to figure out: what's the minimum we can get
away with implementing on the server side without forcing future clients
to implement a lot of undocumented workarounds?)

--b.

> Let's keep in mind that SSV state protection
> was added because it was claimed
> that it was  "too hard" to deploy machine credentials.
> 
> If no one implements SSV state protection, then we should conclude that
> it while it might be hard to deploy machine credentials, but
> implementing the solution is even harder. We can then schedule the
> removal of SSV support from NFSv4.2.
> 
> >
> > --b.
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
> 
> 
> -- 
> Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
> http://blogs.netapp.com/eislers_nfs_blog/
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 6 Jan 2010 16:45:11 -0500

In practical terms, I think deciding what the server "means" isn't all
that important.

If the server gives SERVERFAULT is response to EXCHANGE_ID trying to use
SSV, then what I do I do.  I don't use SSV.  That's true whether he
means he doesn't support it or he thinks he supports it and the support
is buggy and this is a true server-fault.

If you replace SERVERFAULT with SSV_NOT_SUPP, wouldn't the code be
exactly the same except you check for a different value.  The comments
might be a bit different but I don't see that the code would be
significantly different.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Wednesday, January 06, 2010 1:25 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] SSV

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 13 Jan 2010 15:46:31 -0500

> might be a bit different but I don't see that the code would be

So, I figure we're imagining code something like this?:

	ret = do_exchange_id();
	if (ret == SSV_NOT_SUPP)
		if policy_doesn't_require_it:
			ok, turn off ssv and try again.
			ret = do_exchange_id();
		else
			die("bummer, server doesn't support ssv");

And, sure, if you replaced SSV_NOT_SUPP with SERVERFAULT, it'd still be
the same code.  The difference is just that it'd be an undocumented
workaround instead of obvious documented error-handling, so the chances
of it working between two random implementations isn't as high.

But with a spec this large I guess we can live with a few things like
that.

As I said, I just want to list the minimum a server can get away with
implementing without forcing future clients to implement undocumented
workarounds (because we foolishly told people it was safe to start using
a server while it still had some weird shortcuts).

So my current criteria for making that list looks something like:

	- If a feature is mandatory, we've got to implement it.
	- Except if there's some obvious documented negotiation or other
	  mechanism the client can use to recover from its absence.
	- And except if there's a way the client could recover, that may
	  be undocumented, but that's still pretty obvious; and if it
	  looks like nobody else is implementing that feature anyway.

And then I can stop worrying about SSV.  (Though I think that's too bad;
it seemed like a reasonable idea to me.)

--b.