Subject: [nfsv4] Review of draft-ietf-nfsv4-rfc3530-migration-update-01.txt

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 15 Mar 2013 06:34:32 +0000

1) Section 1 vs 3:

   o  The construction and interpretation of the nfs_clientid4 structure

vs

      with the same nfs_client_id4 (id and verifier), when the protocol

2) "state id" vs "stateid"

   both state ids and clientid4's, should be transferred as part of

vs

   stateids associated with a common client boot instance encounters a

I think "stateid" is correct?

3) Where does '(' start?

   For a more complete explanation of the choices made in addressing
   these issues, see [info-migr]).

4)

      confirmation of the new nfs_clientd4 via SETCLIENTID_CONFIRM.

"nfs_clientd4" -> "nfs_client_id4"

6) Do you want to point out that this reference:

   recovery for the server reboot case (See the section entitled "Server
   Failure and Recovery").  In cases of server or client error resulting

is to something in RFC3530[bis] and outside the scope of this document?

Ditto:

   associated stateids (see the section entitled "lock-owner" for
   details).

8) Where is opening '"'?

   o  The uniform client id string approach is used when accessing
      servers that may return NFS4ERR_MOVED and the client wishes to
      enable transparent state migration."

9) "We will"

   is the first one referenced to access that server.  We'll refer to

10) "MUST" or "SHOULD"?

   o  If a matching clientid4 is found which is marked unresolved,
      processing on the new IP address is suspended.  In order to
      simplify processing, there can only be one unresolved IP address
      for any given clientid4.

"there can" sounds like a wiggle.

11)

   o  If one or more matching clientid4's is found, none of which is

"are found"?

12) "do not"

   o  Note that we don't want this to happen if address X is not

13) "SETCLIENTID_CONFIRM"?

   o  If the setclientid_confirm value generated on X is accepted on

14) "One might" -> "The client might"

   o  One might instead serialize the period of processing that begins

   o  One might avoid much of the serialization implied above, by

15) "a" -> "an"

      clients running on the same host, such as a universally unique
      identifier (UUID).

16) This:

   o  The client's network address, or more safely, an address that has
      previously been used in that capacity.

seems to violate:

   o  The algorithm for generating the string should not assume that the
      client's network address is forever fixed.  Changes might occur
      between client incarnations and even while the client is still
      running in its current incarnation.

17) "open-owners" and "lock-owners"

   o  Adding a section describing how information associated with
      openowners and lockowners is to be managed with regard to
      migration.

...

   When clients are implemented to isolate each openowner and lockowner

And further...

18) Again, point out these are in the original:

   sequences described in sections "Operation 35: SETCLIENTID -
   Negotiate Client ID" and "Operation 36: SETCLIENTID_CONFIRM - Confirm
   Client ID".  This ensures that server operations are not delayed due

19) As I read section 5.3.2, all I can think about is F1 is transfered X -> Y,
F2 is transfered X -> Y, and as F3 is transfered X -> Y, F1 is retransfered
Y -> X.

How can the server X determine if F1 is migrated or non-migrated?

20) If there is a network partition or the client reboots, how is the
server aware that the client got the reply to the GETATTR(fs_locations)?

   Note that when the transfer of responsibility leaves remaining state
   for that lease on the source server, the lease is renewed just as it
   would have been in the NFS4ERR_OK case, despite returning the error.
   The transfer of responsibility happens when the server receives a
   GETATTR(fs_locations) from the client for each filesystem for which a
   lease has been moved to a new server.  Normally it does this after
   receiving an NFS4ERR_MOVED for an access to the filesystem but the
   server is not required to verify that this happens in order to
   terminate the return of NFS4ERR_LEASE_MOVED.  By convention, the
   compounds containing GETATTR(fs_locations) SHOULD include an appended
   RENEW operation to permit the server to identify the client getting
   the information.

21) "fh" -> "filehandle"

   GETFH pairs, each pair using an fh in one of the filesystems in

   interrogating the fs_locations attribute for an fh within each of the

(also "an" -> "a")

22) I like the flow of this document much better than the previous one. Some
of the client ID terms are used before definition in Section 4, but once you
hit your stride into that Section, it comes together.

I am not recommending a "Definitions" Section. I think we have to accept the
flow and point out that the reader could familiarize themselves with RFC3530bis.