Subject: questions and comments on draft-ietf-nfsv4-rfc3010bis-02-03.txt

From: Mike Eisler <[email-masked]>
Date: Fri, 09 Aug 2002 04:34:15 -0700

Comments/Questions on draft-ietf-nfsv4-rfc3010bis-02-03.txt.

If these aren't addressed before the WG Chair's deadline,
then consider them the first comments for WG LAST
CALL. These are things that I don't know the answer to,
otherwise I'd have given Spencer text changes.

Should there be an obsolesence statement for RFC3010?

section 18 doesn't list an nfs_lockowner type,
yet the specification has many references to
nfs_lockowner. Something is missing or misreferenced.

Regarding:

   To provide a greater degree of compatibility with previous versions
   of NFS (i.e. v2 and v3), which identified users and groups by 32-bit
   unsigned uid's and gid's, owner and group strings that consist of
   decimal numeric values with no leading zeros can be given a special
   interpretation by clients and servers which choose to provide such
   support.  The receiver may treat such a user or group string as
   representing the same user as would be represented by a v2/v3 uid or
   gid having the corresponding numeric value.  A server is not
   obligated to accept such a string, but may return an NFS4ERR_BADOWNER
   instead.  To avoid this mechanism being used to subvert user and
   group translation, so that a client might pass all of the owners and
   groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
   error when there is a valid translation for the user or owner
   designated in this way.  In that case, the client must use the
   appropriate name@domain string and not the special form for
   compatibility.

I predict that the above will indeed produce mass
subversion.  The original Secure-RPC (aka AUTH_DH) paper
from Goldberg and Taylor (both then of Sun), promised
a scheme similar to user@domain, but it ended up being
implemented as number@domain. Pity.

Regarding,

   If the server continues to hold locks beyond the expiration of a
   client's lease, the server MUST employ a method of recording this
   fact in its stable storage. 

I don't see what (though I vaguely recall understanding
this 3 years ago) holding the locks has to with the stable
storage requirement. Clarification is needed.

Regarding,

   access and deny fields are as follows:

   const OPEN4_SHARE_ACCESS_READ   = 0x00000001;
   const OPEN4_SHARE_ACCESS_WRITE  = 0x00000002;
   const OPEN4_SHARE_ACCESS_BOTH   = 0x00000003;

Since these are constants and not enums, is there an
implication that that if zero and not one of the _ACCESS_
constants are passed to OPEN that a file can be opened
with neither read nor write access? I vaguely recall
someone telling me that in Windows this was possible;
if so, presumably the purpose is would be to merely deny
open access to other potential openers.

Regarding,

   ACCESS4_DELETE  Delete an existing directory entry (no meaning for
                   non-directory objects).

	[...]

     Many implementations do not directly support the ACCESS4_DELETE
     permission.  Operating systems like UNIX will ignore the
     ACCESS4_DELETE bit if set on an access request on a non-directory
     object.  In these systems, delete permission on a file is
     determined by the access permissions on the directory in which the
     file resides, instead of being determined by the permissions of the
     file itself.

The paragraph fragment above seems to imply some
implementations do directly support ACCESS4_DELETE on
non-directories. If so, this contradicts what was first
written about ACCESS4_DELETE.

Regarding,

     Even though CLOSE returns a stateid, this stateid is not useful to
     the client and should be treated as deprecated.  CLOSE "shuts down"
     the state associated with all OPENs for the file by a single
     open_owner.  As noted above, CLOSE will either release all file
     locking state or return an error.  Therefore, the stateid returned
     by CLOSE is not useful for operations that follow.

Given that there is a seqid field in the stateid, is the
above paragraph still true?

Regarding,

     struct open_to_lock_owner4 {
             seqid4          open_seqid;
             stateid4        open_stateid;
             seqid4          lock_seqid;
             lock_owner4     lock_owner;
     };

     struct exist_lock_owner4 {
             stateid4        lock_stateid;
             seqid4          lock_seqid;
     };

     union locker4 switch (bool new_lock_owner) {
      case TRUE:
             open_to_lock_owner4     open_owner;
      case FALSE:
             exist_lock_owner4       lock_owner;
     };

There is very little, if not zero, description as to what
the above is all about. I don't see how we can exit WG last
call without clarification.

Regarding this passage, which appears twice in the specification,

   When the attribute rdattr_error or any write-only attribute (e.g.
   time_modify_set) is specified, the error NFS4ERR_INVAL is returned to
   the client.  If both of these conditions apply, the server is free to
   return either error.

If both of "what" conditions? "either" implies there are
two error codes, but I only see one.

At least two places in the specification say a write
delegation can modify its cached copy of the "change"
attribute:

   The server will use a CB_GETATTR callback, if the GETATTR attribute
   bits include any of the attributes that a write open delegate may
   modify (size, time_modify, change).

AND:

	The client returns attrbits and the associated attribute values
	only for attributes that it may change (change, time_modify, size).

How is this possible? The client has no idea how the server is
constructing the change attribute.

---

From: [email-masked]
Date: Fri, 09 Aug 2002 11:57:14 -0700

>>>>> "mre" == Mike Eisler <[email-masked]> writes:

    mre> Regarding,

    mre>    If the server continues to hold locks beyond the
    mre>    expiration of a client's lease, the server MUST employ a
    mre>    method of recording this fact in its stable storage.

    mre> I don't see what (though I vaguely recall understanding this
    mre> 3 years ago) holding the locks has to with the stable storage
    mre> requirement. Clarification is needed.

This is related to the scenario that appears a few more lines down in
the I-D.  The idea was to let the client recover its locks after a
network partition, as long as nobody else got a conflicting lock
during the partition.  The stable storage part comes in because the
server has to safely remember whether it granted any conflicting
locks.

mike

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 16 Aug 2002 19:00:26 -0500

> Should there be an obsolesence statement for RFC3010?

I will check with the IETF editor on this but I would imagine that
they update the draft to reflect obsolescence statements which is
actually signified by the name of the draft.

> nfs_lockowner. Something is missing or misreferenced.

This is one thing that I changed right before submitting the draft.  I
did a simple replacement of nfs_lockowner with lockowner.  This really
doesn't solve the issue and it more generally addressed by the issue
you raise about the need for a description onf open_to_lock_owner4, etc.

The rest of the issues originally listed I have incorporated into the
recently posted issues list.

Spencer