Subject: Re: comments on draft-ietf-nfsv4-06.txt

From: Spencer Shepler <[email-masked]>
Date: Thu, 01 Jun 2000 18:29:21 -0500

Vern,
  As previous email referenced, I have completed updates to the
NFSv4 I-D.  Below is your original email and I have commented on
each item as to the response and what action was taken.

  Once we close on these items in full, I will submit the draft
for publication as draft-07.

  A version of the draft with change bars is available at:
http://playground.sun.com/nfsv4/draft0601/draft-ietf-nfsv4-06-01.diff

Spencer

Vern Paxson wrote:
> 
> Here are my comments.  They're almost all minor, but enough to merit a
> revision of the document.  By all means feel free to take these issues to
> the WG (either in part or by forwarding my note) for any that you think are
> controversial and/or merit WG discussion.
> 
> One general transport comment: The spec should state that the timers
> maintained by clients and servers must be jittered.  Otherwise, there's
> a risk of inadvertant synchronization.  The classic discussion of this
> problem is:
> 
>         S. Floyd and V. Jacobson,
>         ``The Synchronization of Periodic Routing Messages,''
>         IEEE/ACM Transactions on Networking, 2(2),
>         pp. 122-136, April 1994.
> 

Reference added to bibliography and general comments added to the 
I-D where appropriate.

> It's available off of:
> 
>         http://www.aciri.org/floyd/papers.html
> 
> - Vern
> 
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> >    Lease     An interval of time defined by the server for which the
> >              client is irrevokeably granted a lock.  At the end of a
> 
> typo, irrevocably

I-D change

> 
> >              All leases granted by a server have the same fixed
> >              interval.
> 
> Why is this?  (It may be explained later, but I don't recall.  If so,
> perhaps it would help to add here "(for reasons explained in section X.Y)".

Robinson previously responded.
I-D changed with additional explanatory text.

> >         This data type is used to pass time and date information.  A
> >         server converts to and from local time when processing time
> >         values, preserving as much accuracy as possible. If the
> 
> It's easy to misread this sentence as saying something about time zones
> (i.e., presuming that the server stores time in the local time zone).
> Perhaps fixed with somethiung like "to and from its local representation
> of time"?
> 
> >         set time values.  If set_it is SET_TO_SERVER_TIME4, then the
> >         server uses its local time for the time value.
> 
> (same here)

I-D changed (for both).

> >    If TCP is used as the transport, the client and server SHOULD use
> >    persistent connections.  This will prevent the weakening of TCP's
> >    congestion control via short lived connections.
> 
> It also improves performance (no SYN handshake required), a major win
> over a WAN.

I-D changed.

> >    a filehandle for another file system object.  If the server needs to
> >    reuse a filehandle value, the time elapsed before reuse SHOULD be
> >    large enough that it is likely the client no longer has a cached copy
> >    of the reused filehandle value.
> 
> What's a recommended value for "large enough"?

I-D changed.  Recommendation made that it be 'several hours'.

> >    FH4_VOLATILE_ANY
> >         The filehandle may expire at any time and will expire on during
> 
> expire on -> expire

I-D changed.

> >    Servers which provide volatile filehandles should deny a RENAME or
> >    REMOVE that would effect an OPEN file or any of the components
> 
> effect -> affect

I-D changed.

> >    cansettime         15   boolean        READ     Whether or not this
> >                                                    object's file system
> >                                                    can fill in the times
> >                                                    on a SETATTR request
> >                                                    without an explicit
> >                                                    time.
> 
> It's not clear what this means ("without an explicit time").

I-D changed to the following:

   cansettime         15   boolean        READ     Is the server able to
                                                   change the times for
                                                   a file system object
                                                   as specified in a
                                                   SETATTR operation?

> >    case_insensitive   16   boolean        READ     Are filename
> >                                                    comparisons on this
> >                                                    file system case
> >                                                    insensitive?
> >
> >    case_preserving    17   boolean        READ     Is filename case on
> >                                                    this file system
> >                                                    preserved?
> 
> Are these well-defined for non-ASCII character sets?

Eisler responded.
I-D changed with his suggested text.

> >    homogeneous        26   boolean        READ     Whether or not this
> >                                                    object's file system
> >                                                    is homogeneous, i.e.
> >                                                    whether pathconf is
> >                                                    the same for all file
> >                                                    system objects.
> 
> "pathconf" is not defined.
> 

I-D changed to following:

   homogeneous        26   boolean        READ     Whether or not this
                                                   object's file system
                                                   is homogeneous, i.e.
                                                   are per file system
                                                   attributes the same
                                                   for all file system's
                                                   objects.

> >    numlinks           35   uint32         READ     Number of links to
> >                                                    this object.
> 
> Might clarify that these are hard links.
> 

I-D changed.

> >    owner_group        37   utf8<>         R/W      The string name of
> >                                                    the group of the
> >                                                    owner of this object.
> 
> This is confusing - it sounds like it's the owner's group, but instead
> it should be the group associated with the object, right?
> 

Right.
I-D changed to following:

   owner_group        37   utf8<>         R/W      The string name of
                                                   the group ownership
                                                   of this object.

> >    rawdev             41   specdata4      READ     Raw device
> >                                                    identifier.
> 
> What is this used for?  Things like "df" output?
> 

Robinson responded.
I-D changed to following:

   rawdev             41   specdata4      READ     Raw device
                                                   identifier.  Unix
                                                   device major/minor
                                                   node information.

> >    time_access        47   nfstime4       READ     The time of last
> >                                                    access to the object.
> >
> >    time_access_set    48   settime4       WRITE    Set the time of last
> >                                                    access to the object.
> >                                                    SETATTR use only.
> >
> >    time_backup        49   nfstime4       R/W      The time of last
> > ...
> >    time_create        50   nfstime4       R/W      The time of creation
> >                                                    of the object. This
> 
> How come there aren't _set forms for backup and create?  Seems both
> are needed, particularly time_backup.

Eisler provided a partial response.

The time_backup and time_create attributes are writable so the client
is able to provide a time to the server.  For the time_access_set and
time_modify_set attributes, the data structure allows a specific time
or it allows the client to tell the server to use its local time as
the time for the change or write of this attribute.
For time_backup and time_create, the ability to specify the server's
local time as a value has not been articulated as a requirement.

No I-D update.

> >    quota_avail_soft
> >         The value in bytes which represents the amount of additional
> >         disk space that can be allocated to this file or directory
> >         before the user may reasonably be warned.  It is understood that
> >         this space may be consumed by allocations to other files or
> >         directories though there is a rule as to which other files or
> >         directories.
> 
> What does it matter that there's a rule regarding which other files?

Generalization so that there is some flexibility in how quotas are
implemented at the server.  Provides some vague forewarning as to the
potential complexity of quota policy.

No I-D update.

> >    quota_avail_hard
> >         The value in bytes which represent the amount of additional disk
> >         space beyond the current allocation that can be allocated to
> >         this file or directory before further allocations will be
> >         declined.  It is understood that this space may be consumed by
> 
> "declined" reads more easily as "refused", otherwise it can be confused
> with lowering the quota.

I-D changed.

> >    ACE4_SUCCESSFUL_ACCESS_ACE_FLAG
> >
> >    ACL4_FAILED_ACCESS_ACE_FLAG
> >
> >    Both indicate for AUDIT and ALARM which state to log the event.  On
> >    every ACCESS or OPEN call which occurs on a file or directory which
> >    has an ACL that is of type ACE4_SYSTEM_AUDIT_ACE_TYPE or
> >    ACE4_SYSTEM_ALARM_ACE_TYPE, the attempted access is compared to the
> >    ace4mask of these ACLs. If the access is a subset of ace4mask and the
> >    identifier match, an AUDIT trail or an ALARM is generated.  By
> >    default this happens regardless of the success or failure of the
> >    ACCESS or OPEN call.
> 
> The last sentence is confusing.  If it happens "regardless of the success
> or failure of the ACCESS or OPEN call", then why are there "SUCCESSFUL" and
> "FAILED" variants?

The comparison/check happens regardless of the result of ACCESS or
OPEN so the SUCCESSFUL and FAILED variants still need to exist.

No I-D update.

> >    The bitmask constants used to for the flag field are as follows:
> 
> used to for -> used for
> 

I-D changed.

> >    DELETE                 Permission to Delete the File
> 
> downcase "File"
> 

I-D changed.

> >    SYNCHRONIZE            Permission to access file locally at the
> >                           server with synchronous reads and writes
> 
> This needs some elaboration.  Why does it matter whether the local access
> is synchronous or asynchronous?  Is there any ACE associated with the latter?

There is no ACE for asynchronous.
Carl Beame built the ACL model from what is used in NT and this is an
item that is included for completeness but unfortunately he is
unable to elaborate more on the semantics.

No I-D update.

> >    The bitmask constants used to for the access mask field are as
> 
> used to for -> used for
> 
> >    Who                    Description
> >    _______________________________________________________________
> >    "OWNER"                The owner of the file.
> >    "GROUP"                The group associated with the file.
> >    "EVERYONE"             The world.
> >    "INTERACTIVE"          Accessed from an interactive terminal.
> >    "NETWORK"              Accessed via the network.
> >    "DIALUP"               Accessed as a dialup user to the server.
> >    "BATCH"                Accessed from a batch job.
> >    "ANONYMOUS"            Accessed without any authentication.
> >    "AUTHENTICATED"        Any authenticated user (opposite of
> >                           ANONYMOUS)
> >    "SERVICE"              Access from a system service.
> 
> These smack of legacy support.  If so, it would be helpful to identify
> which systems are being supported.

Again the ACL model was built from NT and as Carl points out,
who entries like "OWNER", "GROUP", and "EVERYONE" are also from
Unix and VMS.  Therefore, they are not strictly legacy for a single
system.

No I-D update.

> >    If the client requests more attributes than fs_locations, the server
> 
> Reads easier if it's "more attributes than [just] fs_locations"

I-D changed.

> >    The server implementor needs to be careful in developing a migration
> >    solution.  The server must consider all of the state information
> >    clients may have outstanding at the server.  This includes but is not
> >    limited to locking/share state, delegation state, and asynchronous
> >    file writes which are represented by WRITE and COMMIT verifiers.  The
> 
> Are there any others known besides the "includes but is not limited to" list?
> It's the "not limited to" that threw me ...

Noveck responded.

No I-D update.

> >    properly.  However with the support of multiple security mechanisms
> 
> Comma after However

I-D changed.

> >         systems have the same address.  In this case, the result is
> >         a switched union that returns in addition to
> >         NFS4ERR_CLID_INUSE, the network address (the rpcbind netid
> 
> Add comma: "returns, in addition"

I-D changed.

> >         the request is returned in error.  For more discussion of
> >         crash recovery semantics, see the section on "Crash
> >         Recovery"
> 
> Add period.

I-D changed.

> >         To mitigate retransmission of the SETCLIENTID operation,
> >         the client and server use a confirmation step.  The server
> >         returns a confirmation verifier that the client then sends
> >         to the server in the SETCLIENTID_CONFIRM operation.  Once
> >         the server receives the confirmation from the client, the
> >         locking state for the client is released.
> 
> The need for the confirmation needs to be clarified using an example.

Added general statement at the beginning of paragraph:

"       It is possible for a retransmission of request to be
        received by the server after the server has acted upon and
        responded to the original client request.  Therefore to
        mitigate effects of the retransmission of the SETCLIENTID
        operation, the client and server use a confirmation step."

I-D changed.

> >    receives a NFS4ERR_STALE_STATEID error using a stateid derived from
> >    its current clientid since this also indicates a server reboot which
> 
> add comma after clientid
> 

I-D changed.

> >    If the server determines that the client holds no associated state
> >    for its clientid and no activity from that client has been received
> >    some long period of time, the server may choose to release the
> 
> Need advice on the suggested "long period of time".

Noveck responded.

I-D changed.

> >    clients.  If the client contacts the server after the this release,
> 
> the this -> this
> 

I-D changed.

> >    locked range, the stateid (previously returned by the server) must be
> >    used to indicate that appropriate lock (record or share) is held.  If
> 
> that the appropriate lock
> 

I-D changed.

> >    Locking is different than most NFS operations as it requires "at-
> >    most-one" semantics that are not provided by ONCRPC.  In the face of
> 
> Mention here that even if over TCP, retransmissions can occur due to
> failed-and-then-reestablished TCP connections.
> 

I-D changed.

> >    If a request with a previous sequence number (r < L) is received, it
> >    is rejected with the return of error NFS4ERR_BAD_SEQID.  Given a
> >    properly-functioning client, the response to (r) must have been
> >    received before the last request (L) was sent.  If a duplicate of
> 
> Can't there in principle be concurrent RPCs, which means that a response
> might not have been received before the last request was sent?

Robinson responded.

No I-D update.

> >    The client is discouraged from coalescing adjacent ranges since the
> >    server may not support sub-range requests and for reasons related to
> 
> Not clear what it means here to coalesce an adjacent range.
> 

Robinson responded.

I-D changed.

> >    The server should take care in the length of delay in the event the
> >    client retransmits the request.
> 
> This shouldn't happen when using TCP, other than for TCP connection failure,
> which takes many minutes to occur.

Robinson responded.

No I-D update.

> >    Clients should be prepared for the return of NFS4ERR_GRACE errors for
> >    non-reclaim lock and I/O requests.  In this case the client should
> >    employ a backoff and retry mechanism for the request.  Timeout
> 
> Need more specifics explaining how the backoff should work.  (Should it
> be exponential?)

Robinson responded.

I-D changed to the following:

"  Clients should be prepared for the return of NFS4ERR_GRACE errors for
   non-reclaim lock and I/O requests.  In this case the client should
   employ a retry mechanism for the request.  A delay (on the order of
   several seconds) between retries should be used to avoid overwhelming
   the server.  "

> >    In the event of a network partition with a duration extending beyond
> >    the expiration of a client's leases, the server MUST employ a method
> >    of recording this fact in its stable storage.  Conflicting locks
> 
> How can the server know if there's a network partition?  It looks the same
> as the client being down, from its perspective.

Robinson responded.

I-D changed to the following:

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

> >    by the client.  As a result of revocation, the client will receive an
> >    error of NFS4ERR_EXPIRED and the error is received within the lease
> >    period for the lock.  In this instance the client may assume that
> 
> Seems there's a race here - "within the least period of the lock" isn't
> tightly defined.  This is worth commenting on even if it really shouldn't
> come up in practice (in which case, that's part of the comment).

Noveck/Robinson responded.

I-D changed.

> >    The LOOKUP operation is preserved and will return a filehandle
> 
> Unclear what "preserved" means here.

"is preserved" removed

I-D changed.

> >    In the event the client reboots or restarts, the failure to renew
> >    leases will result in the revocation of record locks and share
> >    reservations.  Delegations, however, may treated a bit differently.
> 
> may treated -> may be treated
> 

I-D changed.

> >    with these delegations will need to wait.  This behavior is
> >    consistent with the normal recall process may take significant time
> >    because of the client's need to flush state to the server.  This
> 
> "This behavior" sentence is quite hard to parse.

Noveck responded.

I-D changed as suggested.

> >         achieve its purpose.  The other aspect to flushing the data
> >         before close is that the data must be committed to stable
> >         storage before the CLOSE operation is requested by the client.
> 
> It's unclear whether this means committed to stable storage *locally at
> the client* or *on the server*.  Presumably, it's the latter, since the
> client might not have any stable storage.  This occurs again later:

Noveck responded.

I-D changed.

> >    The data that is written to the server as a pre-requisite to the
> >    unlocking of a region must be written to stable storage.  The client
> 
> >    the request using the client's validated cache.  If an appropriate
> >    file lock is not held for the range of the read or write, the read or
> >    write request must not be satisfied by the client's cache and the
> >    request sent to the server for processing.  When a read or write
> 
> "request [must be] sent to the server ..."
> 

I-D changed.

> >    o    For a write open delegation, if, at the time of recall, if the
> >         file is not open for write, all modified data for the file must
> >         be flushed to the server.  If the delegation had not existed,
> 
> "if ... if" in the first sentence scans awkwardly.
> 

I-D changed.

> >         ... If the delegation had not existed,
> >         the client would have done this data flush before the CLOSE
> >         operation.
> 
> This is at odds with the last bullet:
> 
> >    o    Any modified data for the file needs to be flushed to the the
> >         server.
> 
> which sounds like the flush is done anyway.

Noveck responded.

I-D updated.

> Also, "the the" -> "the"

I-D changed.

> >    In the case of modified data existing in the client's cache, that
> >    data must be removed from the client without it being written to the
> >    server.
> 
> Explain why this is necessary.

Noveck responded.

I-D changed.

> >    open file or on the close.  Where the methods available to a client
> >    to make such notification impossible because errors for certain
> 
> "to make" -> "make"
> 

I-D changed.

> >    READDIR operations.  Just as in the cases of attribute and name
> >    caching inconsistencies may arise among the various client caches.
> 
> add comma after "caching"
> 

I-D changed.

> >    To mitigate the effects of these inconsistencies and given the
> >    context of typical file system APIs, the following rules should be
> >    followed:
> 
> Add comma after "inconsistencies"
> 

I-D changed.

> >    are are consecutively allocated), and normalize their offsets to a
> 
> are are -> are
> 

I-D changed.

> >    table that fits in 7 bits.  Thus it is determined that "lower case
> >    alpha" is in the same position as "upper case a" in the US-ASCII
> >    table, and "upper case alpha" is in the same position as "lower case
> >    a" in the US-ASCII table.
> 
> Is it really backwards as this sentence says, that lower case alpha is
> in the same position as *upper* case a, and vice versa?

Eisler responded.

No I-D update.

> 
> >    If the NFS version 4 protocol used a universal 16 bit or 32 bit
> >    character set (or a encoding of a 16 bit or 32 bit character set into
> 
> a encoding -> an encoding
> 

I-D changed.

> >    UTF       UCS transformation format.
> 
> Explain what this means.
> 

Eisler responded.

I-D changed.

> >    a status code (normally zero).  If an operation results in a non-zero
> >    status code, the status will be encoded and evaluation of the
> >    compound sequence will halt and the reply will be returned.
> 
> (You might add that this is even for de facto "non error" conditions,
> such as NFS4ERR_SAME.)

I-D changed.

> >    When an operation is successfully completed at the server, the client
> >    can depend that any data associated with the request is now on stable
> >    storage.  This implies that any previous operations within the same
> 
> Need to qualify this with the possibility of doing an UNSTABLE4 write.
> Otherwise the reader wonders whether all writes have to be synchronous.

I-D changed.

> >      series of operations.  This is useful in operating systems (such as
> >      UNIX) where permission checking is done only when a directory is
> >      opened.  The intent is to make the behavior of opening a remote
> >      file more consistent with the behavior of opening a local file.
> 
> I didn't understand the comment about permission checking; perhaps because
> I have only the UNIX model in my head, so it might help to add an example
> from another OS.

I-D changed.

> >      This operation should also be used by clients which do have
> >      delegation information on stable storage after doing all of
> >      delegation recovery that is needed.  Using DELEGPURGE will prevent
> 
> I found this sentence confusing.

Noveck responded.

I-D changed.

> > 14.2.1.  Operation 3: ACCESS - Check Access Rights
> 
> It doesn't say what happens to the current file handle for a call to ACCESS.
> There are some others for which this is missing, I believe, too.
> 

I-D changed.

> >      Operations that change the current filehandle like LOOKUP or CREATE
> >      do not automatically return the new filehandle as a result.  For
> 
> (why don't they?  Because the old filehandle is often handy to still have
> around?)

While possible, doesn't fit into the general model used to develop the
operations.

No I-D update.

> > 14.2.9.  Operation 11: LINK - Create Link to a File
> 
> There shoud probably be a cross-pointer here to CREATE and symbolic links.
> 

I-D changed.

> >      In the case that the lock is denied, the the owner, offset, and
> 
> the the -> the
> 

I-D changed.

> >              PUTFH  (directory filehandle)
> >              LOOKUP "pub"
> >              GETFH
> >              LOOKUP "foo"
> >              GETFH
> >              LOOKUP "bar"
> >              GETFH
> 
> Explain why the GETFH's are needed.

Robinson responded.

I-D changed.

> 
> >      directory is a server mountpoint.  Unix clients that detect a
> >      mountpoint crossing will need to mount the server's filesystem.
> 
> Explain why they need to - seems the server will happily continue serving
> them even though they've crossed a mountpoint.
> 

I-D changed.

> >      In the case that a client issues an OPEN operation and the server
> >      no longer has a record of the nfs_lockowner, the server needs
> >      ensure that this is a new OPEN and not a replay or retransmission.
> >
> >      A lazy server implementation might require confirmation for every
> >      nfs_lockowner for which it has no record.  However, this is not
> >      necessary until the server records the fact that it has disposed of
> >      one nfs_lockowner for the given clientid.
> 
> It would help to explain exactly what problem we're trying to avoid here
> (what might happen).

Stated in the previous paragraph as a method to prevent unbounded
memory usage.

No I-D update.

> >      first one is a replay.  The server cancels the OPEN state of the
> >      first OPEN requests, establishes an unconfirmed OPEN state for the
> 
> requests -> request
> 

I-D changed.

> >    The access and deny bits speicifed in this operation replace the
> 
> speicifed -> specified
> 

I-D changed.

> >    are subsets of those already granted, it is is not possible for this
> >    request to denied because of conflicting share reservations.
> 
> is is -> is
> to denied -> to be denied
> 

I-D changed.

> >      If the read ended at the end-of-file (formally, in a correctly
> >      formed READ request, if offset + count is equal to the size of the
> >      file), eof is returned as TRUE; otherwise it is FALSE. A successful
> >      READ of an empty file will always return eof as TRUE.
> 
> This sounds like the case of attempting read beyond the end of the file
> (offset + count > size of the file) will return EOF as FALSE.  Is
> that right??

I-D changed with the following:

"    If the read ended at the end-of-file (formally, in a correctly
     formed READ request, if offset + count is equal to the size of the
     file), or the read request extends beyond the size of the file (if
     offset + count is greater than the size of the file), eof is      
     returned as TRUE; otherwise it is FALSE.  A successful READ of an 
     empty file will always return eof as TRUE."

> >      data. If the server returns less than the count requested and eof
> >      set to FALSE, the client should issue another READ to get the
> 
> eof set -> eof is set
>         reads more clearly

I-D changed.

> >      several circumstances. The file may have been truncated by another
> >      client or perhaps on the server itself, changing the file size from
> >      what the requesting client believes to be the case. This would
> 
> Another possibility is that the client hasn't bothered to computed exactly
> what size reads it should issue to precisely consume the file, right?

Yes.

No I-D update.

> >      This value is the XDR encoded length of the name of the directory
> >      entries and the cookie value for the entries.  The server may
> 
> It's easy to misread this sentence as saying "the value is itself XDR
> encoded, and it's a length" rather than "the value is a length of an
> XDR-encoded object"
> 

I-D updated with:

"    This value represents the length of the names of the directory     
     entries and the cookie value for these entries.  This length       
     represents the XDR encoding of the data (names and cookies) and not
     the length in the native format of the server.  The server may     
     return less data."

> >      On successful return, the server's response will provide a list of
> >      directory entries.  Each of these entries contains the name of the
> >      directory entry, a cookie value for that entry, and the associated
> 
> Each entry has a cookie?  Why?  So the client can pick up reading at
> any one of them?  Is that indeed needed?

Yes. The client can start reading the directory with any cookie
value provided by the server.  This behavior is the same with
previous versions of NFS.

> >      Ideally, the cookie value should not change if the directory is
> >      modified.
> 
> Explain why - what happens if it does?

I-D changed.

> >      response.  To enable some client environments, the cookie values of
> >      0, 1, and 2 are to be considered reserved.  For READDIR arguments,
> 
> How can the client care about these magic cookie values, when it's already
> stated that they're opaque to the client?  It sounds like something more
> is going on here (i.e., a particular legacy feature/hack is being supported),
> and it would be helpful to spell it out.

I-D changed.

> >      Since the server will not be returning "." and ".." entries as has
> 
> Since the server -> Since some servers
> 

I-D changed.

> >      The READLINK operation is only allowed on objects of type, NF4LNK.
> 
> Delete comma
> 

I-D changed.

> >      resources (disk space, directory entry, and so on.) formerly
> 
> Delete period
> 

I-D changed.

> >      the file will still be accessible. The usual mechanism used is to
> >      use RENAME to rename the file from its old name to a new hidden
> >      name.
> 
> This would read more easily if "use RENAME to rename" -> "RENAME"
> 

I-D changed.

> >      The stateid is necessary for SETATTRs that change the size of file
> 
> size of file -> size of a file
> 

I-D changed.

> >      The principal or principal to user identifier mapping is taken from
> 
> This reads awkwardly.
> 

I-D changed.

> >      existing clientids.  If the client is a traditional host based
> 
> host based -> host-based
> 

I-D changed.

> >      the host credential.  If the client is a user level client or light
> >      weight client, the credential used may be the end user's
> 
> light weight -> lightweight
> 

I-D changed.

> >      The client must use the SETCLIENTID_CONFIRM operation to confirm
> >      its use of client identifier.  Once the server receives the valid
> >      confirmation, all state previously held by the client (if
> >      applicable) is kept until the receipt of the SETCLIENTID_CONFIRM is
> >      successful.  Upon successful confirmation the server will release
> 
> This is confusing - it sounds like "once the server receives the valid
> SETCLIENTID_CONFIRM confirmation, it keeps all state until it receives
> a SETCLIENTID_CONFIRM", but of course it just did ...

I-D changed with the following:

"    The client must use the SETCLIENTID_CONFIRM operation to confirm
     its use of client identifier.  If the server is holding state for a 
     client which has presented a new verifier via SETCLIENTID, then the 
     state will not be released, as described in the section "Client     
     Failure and Recovery", until a valid SETCLIENTID_CONFIRM is         
     received.  Upon successful confirmation the server will release the 
     previous state held on behalf of the client.  The server should     
     choose a confirmation cookie value that is reasonably unique for    
     the client."

> >      struct WRITE4resok {
> >              count4          count;
> >              stable_how4     committed;
> >        verifier4writeverf;
> >      };
> 
> Is this last supposed to be indented and given a name "verf"?  That's
> what appears to be the case from the text.

I-D changed.

> >      Some implementations may return NFS4ERR_NOSPC instead of
> >      NFS4ERR_DQUOT when a user's quota is exceeded.
> 
> Why is that?

Some server implementations are unable to or find it very difficult to
determine the exact source of a failed write (NOSPC|DQUOT) so this
statement is present to relieve implementation burden.

> > 15.2.  Procedure 1: CB_COMPOUND - Compound Operations
> >
> > ...
> >    ERRORS
> >
> >      All errors defined in the protocol
> 
> (actually, it can't return them all, or even close ...)

I-D changed.

> >      The client returns attrbits and the associated attribute values
> >      only for attributes that it may change (change, time_modify,
> >      object_size).  It may further limit the response to attributes that
> >      it has in fact changed during the scope of the delegation.
> 
> Why would it bother limiting the response to just those that have
> changed?  Surely this is a very minor savings ... ?

Noveck responded.

I-D changed.

> >    via an information RFC.  This will provide for interoperability where
> 
> an information -> an Informational
> 

I-D changed.

> >            NFS4ERR_STALE           = 70,
> >            NFS4ERR_BADHANDLE       = 10001,
> 
> Why the skip in numbering between these two?

Historic (defined this way for NFSv3 so it was carried forward).

> >    /*
> >     * ACE4_GENERIC_WRITE -- defined as combination of
> >     *      ACE4_READ_ACL |
> >     *      ACE4_WRITE_DATA |
> >     *      ACE4_WRITE_ATTRIBUTES |
> >     *      ACE4_WRITE_ACL |
> >     *      ACE4_APPEND_DATA |
> >     *      ACE4_SYNCHRONIZE
> >     */
> >    const ACE4_GENERIC_WRITE = 0x00160102;
> 
> The constant is missing ACE4_APPEND_DATA, it should be 0x00160106.

I-D changed.