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