From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 01/23/03-02:57:05 PM Z
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A072A3C@SILVER.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: NFSv4 Advisory vs. Mandatory locking issues
Date: Thu, 23 Jan 2003 12:57:05 -0800
> David [Robinson] wrote:
>
> >> The NFSv4 protocol does not support or restrict the use of nonstandard
NFS
> >> implementations to satisfy customer solutions.
> >
> >As a clarification, nonstandard implementations are by definition
> >not "NFSv4" and should not be called NFSv4. This is a common
> >confusion in the IETF, if you use the term NFSv4 it is
> >standards conforming, anything else should have it's own
> >name (e.g. Bob's FS). Otherwise there is no way to distinguish
> >between an implementation that has changed just one required
> >feature and another that is loosely based on NFSv4 (think DAFS).
>
> This is the area I'm unfamiliar with and appreciate your responses.
>
> I support the IETF/WG need to draw the line and define boundaries. From
> the
> protocol perspective, the only real "NFS" server product are those that
> support all the procedures and provide the expected results outlined in
> the draft. Nothing more, nothing less.
The spec is not very rigid as far as a lot of expected results. In part,
this is because of the idea that NFS-v4 is not supposed to define
file system semantics but is merely a protocol so that the client can
make requests and results as defined by the servers semaantics refelcted
to the client. I actually think a larger part is due to the fact that
we'd like the spec to be under a thousand pages. Nevertheless, the
spec does contain a lot of material that sure seems like semantics to
me. I'm not saying this apparent contradiction cannot be resolved,
but I am saying that I can only do it in a limited set of cases.
> Where we got into trouble is certain platforms may not be able to support a
> particular NFS draft item and therefore implemented a failure type
> restriction "I can't do that" which is not defined in the protocol.
I think you have to stay within the errors defined for a given op.
Otherwise you are not obeying the protocol. Usually you can find an
error that sort of works.
> An
> example would be a server not able to support delegation for reasons
> entirely
> of it's own,
Delegations are not a required feature. The protocol is so constructed
that you are not obliged to return delegations. It is up to the server.
If he doesn't want to return one in any given situation or all situations,
the spec offers no reproaches.
> or not support file share semantics.
I don't see why a server is not able to do this, at least within the
context of other v4 opens? I can see that it might be problematic to
exclude non-v4 opens but I think the basic idea is that the spec doesn't
cover that (Although angry customers might have their own opinions).
> The problem is deciding if this product can still be labeled NFS, or
> does IETF/WG not accept this as an NFS product because of the restriction.
> The answer of not NFS may affect the goal of NFS acceptance and
> availability.
> It seems like we are at a point where restrictive offerings may call
> themselves NFS without anyone forcing them to change their name to Bob's
> FS.
I've never heard of the IETF forcing someone to change the name of
their product because they returned NOTSUPP is some case not mandated
by the spec. But I'm not really up on IETF lore.
> Even though by protocol definition they are not NFS due to their
> restrictive
> nature. I'm only describing restricting function, not adding additional
> function.
>
> What are the ramifications of incorporating non-NFS restrictions to satisfy
> platform limitations or limitations to support customer requirements and
> labeling your product as NFS?
The problem
in defining "NFS" products
-David
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:48 AM Z CST