Telechat Review of draft-ietf-nfsv4-rfc3530-migration-update-07
review-ietf-nfsv4-rfc3530-migration-update-07-opsdir-telechat-kuarsingh-2016-01-25-00

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 - 


tools.ietf.org/html/draft-ietf-nfsv4-rfc3530-migration-update-07




Summary:



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 


specification).






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 


rewritten).






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”…