Skip to main content

Telechat Review of draft-ietf-nfsv4-rfc3530-migration-update-07

Request Review of draft-ietf-nfsv4-rfc3530-migration-update
Requested revision No specific revision (document currently at 08)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2016-01-19
Requested 2016-01-04
Authors David Noveck , Piyush Shivam , Chuck Lever , Bill Baker
I-D last updated 2016-01-25
Completed reviews Genart Last Call review of -07 by Elwyn B. Davies (diff)
Genart Last Call review of -07 by Elwyn B. Davies (diff)
Opsdir Telechat review of -07 by Victor Kuarsingh (diff)
Assignment Reviewer Victor Kuarsingh
State Completed
Request Telechat review on draft-ietf-nfsv4-rfc3530-migration-update by Ops Directorate Assigned
Reviewed revision 07 (document currently at 08)
Result Has issues
Completed 2016-01-25
Dear Authors,

I have reviewed this document as part of the Operational directorate's 

ongoing effort to review all IETF documents being processed by the 

IESG.  These comments were written with the intent of improving the 

operational aspects of the IETF drafts. Comments that are not addressed 

in last call may be included in AD reviews during the IESG review.  

Document editors and WG chairs should treat these comments just like any 

other last call comments.

Document Reviewed - NFSv4.0 Migration: Specification Update

Link to Document -


The document is focused on specification updates to RFC7530 (NFSv4.0) to 

address challenges with filesystem migrations.  The document provides a 

description of the observed challenges, and seeks to replace certain 

sections of RFC7530 with updated specifications and guidelines.  

Additional information is covered not originally included in RFC7530 

(such as Server Implementation Considerations).

General Comments and Feedback:

The document provides significant updates to sections in RFC7530 which 

covered the Client ID (Section 9.1.1. in RFC7530), Server Release of 

Client ID (Section 9.1.2 in RFC7530) and Migration, Replication and 

State (Section 9.14 in RFC7530).

The documents writing style is very conversational in a number of 

places, and it’s does make it difficult to follow the general flow. Many 

of the requirements (both new and updated) are captured both in bullet 

form, and in body text, which makes is difficult at times to parse the 

full implementation requirements.  However, the requirement appear to be 

captured with a full read of the document.

It may be advisable to reconstruct the document’s structure to better 

split out the three key areas which include: (1) input experience and 

needed changes, (2) specification text [updated and new], (3) 

implementation recommendations and guidance.  This may make if easier to 

understand and compare to RFC7530 (which is needed to implement the full 


Although changes made to the ClientID4, as an example, are well covered 

in the document, and mapped to how these changes affect migrations (and 

related functions such as state tracking, locking, etc), it’s not fully 

understand or described on how these changes affect the other 

specification areas which are captured in RFC7530. Although the changes 

are focused on filesystem migrations, the changes would also have 

overall affect on the full specification implementation as it relates to 

other aspects of NFSv4.0.  I don’t have a strong suggestion on how to 

address this in an easy manner, but perhaps a quick listing of the 

RFC7530 specification areas with a quick note as to the expected affect 

(which may be none, moderate or large) would be beneficial to the 

implementer / reader.

Given discusses on data tracker related to security implications to the 

changes, I did not make specific note of those here.

Some textual feedback is included below (text update recommendations).

Feedback / Review:

Proposed text: (only a suggestion)

“ The migration features of NFSv4 allows the responsibility for a single 

filesystem to move from one server to another, without disruption to 

clients.  Recent experience has exposed implementation challenges with 

the existing specification in relation to the file system migration 

feature in NFSv4.0.  This document identifies the problem areas along 

with revised specification text which updates the NFSv4.0 specification 

documented in RFC7530.”

Section 4.2

Pg. 6, Par:1

Paragraph 3, I would make this a sub-section called “Client ID 

generation considerations” to make it clear it’s incremental information 

on how the client ID is generated (easier to identify in body text).

Paragraph 3, End of point 1 seems redundant to point  5. (i.e. “the 

string MAY be redundant for each server network address”)

Point 6, sub-paragraph 1.  Suggested text for first sentence. “The 

algorithm for generating the string should not assume that the clients’ 

network addresses will be persistent for any set period of time.”

sub-paragraph 2, suggested first sentence.  “Changes to the client ID 

string in relation to network address changes would result in…”

sub-paragraph 3, second sentence suggested text.  “In such a use case, a 

client, if using the same algorithm, would generate a conflicting client 

id string”.

Section 4.4

Paragraph 1, first sentence is difficult to parse (may need to be 


Paragraph 3, bullet 1, would change the use of the word “occasion” to 

perhaps “requirement” or “need”

I would also change the intro sentence in paragraph 3 to something like 

- “NFS has evolved and traditional versions of NFS were stateless.  

NFSv4.0 has introduced new requirements such as the need for a Client ID 

which has created challenges with implementations.

Section 4.8

Paragraph 2, bullet 4.  Normative statement “Servers MUST NOT do that” 

made, but not clear it’s intended as a requirement.

Clarity on how section 4.0 maps into sections 9.1.1 and 9.1.2 in RFC7530.

Section 5 (replacement for Section 9.14 in RFC7530)

Section 5.1

Paragraph 2, sentence is awkward “If a server replica or a server 

immigrating a filesystem agrees to,

   or is expected to”…